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ABSTRACT 


‘Experience  has  shown  that  the  traditional  method  of 
software  development  often  has  poor  results.  Recently,  a 
new  approach  to  software  development,  the  prototype 
approach,  has  been  proposed.  This  thesis  presents  an  inte¬ 
grated  view  cf  general  design  theories  and  relates  that  view 
to  software  design  and  development.  The  current  thought  on 
prototypes  is  described  and  the  basic  reguireaents  for  a 
software  engineering  environment  are  presented.  Software 
prototypes  are  shown  to  support  the  integrated  view  of 
design.  Four  case  studies  cf  using  prototypes  are  presented 
and  recommendations  fcr  further  study  are  made. 
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I.  IN TBQDPCTI08 

Current  software  engineering  practices  are  based  on  a 
development  model  which  is  10  to  15  years  old. ,  This  model 
is  often  referred  to  as  the  waterfall  model.  The  waterfall 
model  shows  the  development  of  software  as  a  series  of 
discrete  steps  [Ref.  1,  2,  3,  4,  and  5]. 

Experience  indicates,  however,  that  software  development 
is  net  as  discrete  as  the  model  indicates,  so  the  model  has 
teen  refined  by  adding  loops  between  each  of  the  steps. 
Furthermore,  as  software  maintenance  has  gained  recognition, 
there  is  increased  pressure  to  refine  the  waterfall  model  to 
show  the  added  importance  of  maintenance  in  the  software 
life-cycle. 

The  software  engineering  profession's  concern  about 
software  maintenance,  which  is  mere  properly  termed  refine¬ 
ment  and  enhancement,  has  prompted  several  conjectures. 
Dodd  [Hef.  20]  has  suggested  that  the  current  cycle  of 
develop,  implement,  refine  and  enhance,  implement,  refine 
and  enhance,  implement,  and  so  on  is  really  the  construction 
and  refinement  of  a  prototype  system. 

Several  other  authors  have  suggested  that  we  should 
develop  software  prototypes  as  an  alternative  to  the  tradi¬ 
tional,  or  waterfall,  approach  to  software  development 
[Ref.  68,  36,  62].  Their  principal  argument  is  that  the 
process  cf  software  development  is  really  iterative,  slowly 
expanding  toward  a  completed  system.  Other  reasons  include 
enhanced  communications  between  the  user  and  designer,  fewer 
requirements  problems,  quicker  turnaround  between  initial 
system  need  and  initial  system  implementation,  to  name  a 
few. 
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The  process  of  developing  a  software  prototype  has 
significart  intuitive  appeal  for  users  and  managers;  they 
can  try  a  system  cut  before  committing  themselves'  to  a 
system  which  is  either  unsatisfactory  or  undelivered.  Aside 
from  this  appeal  and  the  benefits  often  cited,  there  seems 
to  be  little  discussion  about  the  principles  underlying  the 
development  of  software  prototypes. 

This  thesis  presents  cne  view  of  how  the  process  of 
developing  software  prototypes  supports  some  basic  elements 
of  general  design  theory  and  software  design  specifically. 
Chapter  II  develops  an  integrated  set  of  design  elements 
based  cn  several  published  models  of  the  general  design 
process.  Chapter  III  relates  these  design  elements  to  soft¬ 
ware  development  by  citing  examples  from  the  computing  and 
information  science  literature.  The  purpose  is  to  show  that 
software  design  is  similar  to  other  fields  of  design.1 

Chapter  IV  introduces  the  software  prototype.  The 
process  of  developing  software  prototypes,  their  roles  as 
models,  construction  strategies,  and  the  principal  uses  of 
prototypes  are  described.  The  chapter  concludes  by  shewing 
how  prototypes  support  the  design  elements  from  Chapters  II 
and  III.  Chapter  V  briefly  describes  the  essential  features 
cf  software  engineering  environments,  especially  those 
features  which  are  needed  for  developing  software  proto¬ 
types.  Chapter  VI  presents  four  case  examples  which  illus¬ 
trate  the  process  of  developing  a  software  prototype.  These 
cases  were  chosen  because  in  each  of  them  there  was  an 
explicit  decision  to  use  prototypes.  Chapters  VII  and  VIII 
present  Conclusions  and  Recommendations  for  Further  Study. 


4 To  paraphrase  Gertrude  Stein; 
design  rs  design. 


Design  is  design  is 


A.  STBOCTOBED  MODELS  OF  DESIGB 


The  ideas  about  design  and  design  methods  have  undergone 
some  significant  changes  in  the  last  20  years.  The  early 
■odels  placed  their  emphasis  on  the  process  o£  design. 
These  models  had  a  rational,  discrete  notion  of  design  in 
which  the  design  process  was  thought  to  be  a  sequence  of 
well-defined,  highly  structured  activities.  Many  theorists 
applied  the  ideas  and  principles  of  the  scientific  method  to 
the  process.  Alexander  (Ref.  6]  was  one  of  the  earliest  of 
the  design  theorists  to  carefully  explain  design.  His  three 
most  significant  contributions  were: 

1.  The  symmetry  cf  the  design  problem — that  is,  design 

has  two  symmetical  parts,  the  form  (the  solution  to 
the  problem)  and  the  context  (the  setting  which 
defines  the  problem)  .  "...  adaptation  is  a  mutual 

phenomenon  referring  to  the  context's  adaptation  to 
the  form  as  much  as  the  form's  adaptation  to  it's 
context  ..."  The  design  problem  is  an  effort  to 
achieve  "fitness"  between  the  form  and  it's  context. 
(Bef.  6] 

2.  The  formal  decomposition  of  a  set  of  requirements 
into  successively  smaller  subunits. 

3.  The  importance  of  diagrams  in  design.  A  diagram,  for 

Alexander,  is  "(a]ny  pattern  which,  by  baing 

abstracted  from  a  raal  situation,  conveys  the  phys¬ 
ical  influence  of  certain  demands  or  forces  ..." 
(Bef.  6:  p.  85] 
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Alexander  chose  tc  emphasize  the  process  of  decompose  ion 
in  his  early  work.  This  process  was  divided  into  two 
phases,  analysis  and  synthesis. 

In  analysis,  the  designer,  faced  with  a  problen,  derives 
a  Mental  picture--often  7ague  and  unsatisf actory--of  the 
demands  of  the  contsxt,  and  then  decomposes  that  picture 
into  sets  (a  mathematical  picture)  .  Synthesis  begins  by 
developing  diagrams  (based  on  the  sets) ,  using  the  diagrams 

to  form  a  design,  and  then  deriving  the  fora  (see  Figure 

2.1).  Alexander  also  discussed  evaluation  (he  calls  it 
"goodness  of  fit").  Goodness  of  fit  is  determined  by  one  of 
two  criteria,  experimental  or  non -experimental.  The  experi¬ 
mental  criterion  is  trial  and  error  where  "[t]he  experiment 
of  putting  a  prototype  form  in  the  context  itself  is  the 
real  criterion  of  fit."  [Bef.  6:  p.  21].  The  r.cn- 

exper imental  criterion  is  "(a]  complete  unitary  description 
of  the  demands  made  by  the  context  ..."  [Bef.  6:  p.  21]. 

Alexander  believes  that:  1)  trial  and  error  is  too  expensive 
and  too  slow  and  2)  there  is  no  theory  which  can  express 
"...  a  unitary  description  of  the  varied  phenomena  of  a 
particular  context."  [Bef.  6:  p.  20].  For  these  reasons 
he  concentrates  on  the  process  of  decomposition. 2 

Alexander’s  structured  view  was  shared  by  many  theorists 
during  the  early  1960's.  [Bef.  8,  7].  Archer  (Bef.  7] 
thought  of  design  as  a  goal-directed  activity.  The  goals  or 
objectives  of  the  prcblem  define  the  properties  required  in 
the  solution.  The  details  of  the  design  are  the  designer's 
decisions  about  how  tc  implement  those  properties  [Bef.  7: 
p.  286]. 


2  Alexander  devotes  an  entire  Appendix  to  the 
"Mathematical  Treatment  of  Decomposition." 
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Figure  2.1  Alexander's  Design  Phases. 
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ircher  identifies  three  components  of  the  design 
process: 

1.  The  advance  through  the  project  and  through  time; 

2.  The  branching  cf  the  problem  into  its  logical  parts; 
and, 

3.  k  problem-solving  process  cyclically  moving  through 
sotproblems  (using  a  30-step  reiterative  operational 
mcdel) . 

Jones  [Bef.  8]  called  the  three  stages  in  his  view  of 
the  design  process  divergence,  transformation,  and  conver¬ 
gence.  He  was  quite  convinced  that  designers  should  think 
of  these  stages  as  separate: 

...there  is  little  doubt  that  their  separation  is  prere¬ 
quisite  to  whatever  changes  of  methodology  are  necessary 
at  each  stage  before  they  can  be  reintegrated  to  form  a 
process  tha£  works  well  at  the  systems  level.  [Bef.  8: 
p.  64] 


E.  0ICKEE  EBOBLEBS 

These  early  models  ware  often  criticized.  One  critique 
suggested  that  design  problems  are  "wicked  problems"  and  are 
not,  therefore,  amenable  tc  structured  analysis  (and  decom¬ 
position).  The  term  "wicked  problem"  refers  to  a 

....  class  of  social  system  problems  which  are  ill- 
formulated,  where  the  information  is  confusing,  where 
there  ape  many  clients  and  decision-makers  with 
conflicting  values,  and  where  the  ramifications  in  the 
whcle  system  are  thoroughly  confusing.  [Bef.  9] 

Wicked  problems  have  the  following  properties  : 

1.  Wicked  problems  ae  ill-formulated.  They  have  no 
definitive  formulation  and  any  formulation  will 
correspond  tc  the  formulation  of  the  solution.  This 
means  that  any  time  a  formulation  is  made,  additional 
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questions  can  be  asked  and  more  information  can  be 
requested.  This  also  means  that  the  information 
needed  to  understand  the  problem  is  determined  by 
one's  idea  or  plan  of  a  solution.  In  other  vcrds, 
whenever  a  wicked  problem  is  formulated  there  must 
already  be  a  solution  in  mind. 

2.  nicked  problems  have  no  stopping  rule.  Any  time  a 
solution  is  formula  ted ,  it  could  be  improved  or 
worked  on  more.  One  can  stop  only  because  one  has 
run  cut  of  resources,  patience,  etc.  (An  architect 
could  keep  modifying  and  improving  a  design  solution 
fciever--he  steps  because  he  has  exhausted  his  fee, 
because  the  building  has  to  be  finally  built,  or 
because  he  has  exhausted  some  other  resource.) 

3.  Solutions  to  wicked  problems  cannot  be  correct  or 
false.  They  can  only  be  good  or  bad.  (There  is  no 
correct  or  false  building:  there  can  only  be  a  "good" 
building  or  a  "bad"  building.) 

4.  In  solving  wicked  problems  there  is  no  exhaustive 
list  of  admissable  operations.  Any  conceivable  plan, 
strategy  or  act  is  permissable  in  finding  a  solution 
and  none  can  be  perscribed  as  mandatory. 

5.  For  every  wicked  problem  there  is  always  more  than 
cne  possible  explanation.  The  selection  of  an  expla¬ 
nation  depends  on  the  employed  world-view;  the  expla¬ 
nation  also  determines  the  solution  to  the  problem. 
(The  high  cost  of  construction  of  a  building  may  be 
attributed  to  the  "expensive"  design,  to  the  high 
cost  of  materials,  to  the  wages  demanded  by  unions, 
to  high  interest  rates  and  inflation,  etc.) 

6.  Every  wicked  problem  is  a  symptom  of  another  "higher 
level"  problem.  (If  the  maintenance  of  the  residence 
is  "too  expensive"  tc  its  inhabitants,  this  indicates 
that  there  is  a  problem  with  the  income  of  its  inhab¬ 
itants.  ) 
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Mo  wicked  problem  and  no  solution  to  it  has  a  defini¬ 
tive  test.  In  ether  words,  any  time  any  test  is 
"successf ally "  passed  it  is  still  possible  that  the 
solution  will  fail  in  some  other  respect.  (If  large 
windows  are  designed  for  a  residence  to  provide  the 
desired  views,  the  heating  of  the  residence  may 
become  too  expensive.) 

8.  Each  wicked  pzcblem  is  a  "one  shot"  operation.  There 
is  nc  room  for  trial  and  error,  and  there  is  no 
possibility  for  experimentation.  (A  house  is 
designed  and  built- -there  is  no  going  back  to  the 
beginning  to  redesign  and  rebuild  it.) 

9.  Every  wicked  problem  is  unique.  Mo  two  problems  are 
exactly  alike  and  no  solutions  or  strategies  leadina 
to  solutions  can  readily  be  copied  for  the  next 
problem.  (Even  if  two  residences  are  designed  for 
the  same  family,  under  the  same  geographical  condi¬ 
tions  they  will  never  be  identical.) 

10.  The  wicked  problem  solver  has  nc  right  tc  be 
wrong — he  is  fully  responsible  for  his  action. 

If  design  problems  are  considered  as  wicked  problems, 
they  are  certainly  incompatible  with  the  early  models  of 
design.  The  early  models  clearly  separated  the  problem  from 
its  solution.  With  wicked  problems,  one  cannot  "define  the 
problem" — they  have  no  definitive  formulation.  If  one 
followed  the  procedures  of  the  early  models  of  design,  one 
.  should  be  able  to  establish  when  a  solution  was  clearly 
found.  Kicked  problems,  however,  have  no  stopping  rule. 
Some  cf  the  proponents  of  the  early  models  of  design  devised 
tests  for  design  solutions.  Alexander  argued  that  trial  and 
error  should  eventually  lead  to  "good  fit";  unfortunately, 
each  time  a  solution  is  tried,  the  problem  is  also  changed. 


C.  ACCUMULATED  KHOSIBDGE  MODELS  OF  DESI6I 


1 .  Design  is  Argumentative 

Other  design  models  were  proposed  following  the  criti¬ 
cisms  of  the  early,  structured  models  of  design.  Rittel 
[Hef.  13]  views  the  whole  design  process  as  sequential 
problem  solving  in  which  the  cycles  fora  networks.  An 
essential  part  of  this  model  is  the  continuous  feedback 
between  the  designer  and  the  problems  environment.  Rittel 
calls  this  •  argumentation* : 

....  the  designer  [is]  arguing  toward  a  solution  with 
himself  and  with  ether  parties  involved  in  the  project. 

He  builds  a  case  leading  to  a  better  understanding  of 
what  is  to  be  acccadisfi ed.  In  its  course,  solution 
principles  are  developed,  evaluated  in  view  of  their 
expected  performance  and  decided  upon.  The  Darties 
commit  themselves  to  specific  courses  of  action  ‘and  to 
the  risks  involved  in  them.  In  this  way,  better  formu¬ 
lations  of  the  problem  are  being  developed  simultane¬ 
ously  with  a  clearer  and  clearer  image  of  the  solution. 

[  Ref.  13  s  p.  19-20] 

If  arguments  are  improved  procedurally ,  their  content  may 
improve  and  the  products  of  the  design — design 
decisions — may  also  be  expected  to  improve.  While  ’argu¬ 
ing',  the  parties  may  gain  new  insights  about  the  issue, 
expand  their  world-view,  modify  challenged  positions,  and 
learn  more  about  other  world-views. 

2.  Patterns  in  lesion 

Alexander  introduced  the  concept  of  pictoral 
diagrams  in  design  in  1964  [Ref.  6].  Significantly, 
Alexander  believed  that  the  design  diagrams  were  produced  by 
formal.  liaojojig  analysis,  a  design  process  founded  cn  math¬ 
ematical  decomposition.  Since  then,  Alexander  and  ethers 
[Rmf.  10]  have  concentrated  on  the  diagrams  (or  Patterns) 
rather  than  the  process. 
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Alexander's  patterns  are  not  a  resalt  of  rigcrcus 
analysis.  Rather,  design  is  a  process  of  acquiring  Knowl¬ 
edge  and  then  Baking  decisions  which  reflect  that  knowledge. 
The  crucial  issue  for  Alexander  is  the  availability  of 
knowledge.  That  is,  the  design  decision  depends  on  the 
accuaulated  knowledge  of  the  designer.  Patterns  help  to 
provide  the  designer  with  the  necessary  knowledge  to  solve 
the  problea.  The  pattern  foras  the  basis  of  communication 
between  the  designer  and  the  client.  A  pattern  —  a  diagraa 
of  what  the  designer  knows  and  believes  iaportant  for  the 
problea — is  designed  and  then  passed  to  the  client.  The 
client  either  accepts  or  does  not  accept  the  pattern.  In 
either  case,  bcth  the  client  and  the  designer  gain  new 
knowledge:  if  the  pattern  is  not  accepted,  the  designer 
proceeds  to  change  the  design. 


3.  Resign  as  Learning 


Eazjanac  £  Ref .  15]  views  the  design  process  as 
formulating  the  problea  and  proceeding  with  a  search  for  The 
definition  of  the  solution.  He  emphasizes  that  the  formula¬ 
tion  cf  the  problea  is  not  final.  The  formulation  reflects 
the  understanding  of  the  problem,  based  on  the  designer's 
knowledge,  at  that  tlae. 


Any  solution  ...  is  already  basically  determined  by  thc- 
derinition  of  the  problem.  So  The  "search  for  solution" 
is  then  the  search  fq>r  the  definition  of  the  specific 
solution  which  best  fits  the  knowledge  the  designer  has 
at  that  time.  Once  the  specific  solution  is  defined  it 
is  documented.  .  Documentation  may  start  during  the  defi¬ 
nition  cf  the  problea  and  continue  sporadically  during 
the  definition  of  the  solution — in  fact,  all  three 
nhases  nay  at  tiaes  take  place  simultaneously.  The 
ultimate  purpose  of  the  documentation  is  tc  communicate 
the  definitions  of  the  problem  and  the  solution;  its 
immediate  purpose  is  to  aid  the  designer  in  the  defini¬ 
tion  cf  the  problea  and  the  solution--to  help  him  detect 
new  aspects  of  the  problea  and  the  solution  and  to 
detect  inconsistencies  in  his  view.  [Ref.  15] 


Curing  the  search  and  redefinition,  the  designer 
keeps  learning  aore  about  the  problem  and  the  solution.  The 
designer  gains  new  insights  which  ultimately  lead  to'  a  new 
view —  redefinition.  The  process  (formulate  the  problem, 
search  for  the  definition  of  the  solution,  document  the 
specific  solution)  is  repetitive.  The  designer  continues  to 
re-define  and  document  new  formulations  until  1)  the  incre¬ 
mental  gain  in  knowledge  becomes  insignificant  and  cannot 
change  the  formulation  enough  to  warrent  redefinition,  2) 
the  incremental  gain  becomes  too  costly,  or  3)  the  designer 
exhausts  available  resources  (especially  time). 


4.  Cesign  is  Satisficing 

As  the  designer  and  user  learn  more  about  the 
problem  and  as  the  sclution  becomes  clearer,  more  and  more 
design  decisions  are  negotiated  [Bef.  13,  15].  Since  these 
design  decisions  are  reached  through  compromise,  they  cannot 
be  called  optimal,  in  the  sense  of  management  science  and 
operations  research. 

Simcn  (Bef.  14]  has  introduced  the  idea  of  satis¬ 
ficing  tc  describe  these  kinds  of  negotiated  decisions. 


Normative  economics  has  shown  that  exact  solutions  to 
the  large  optimization  problems  of  the  real  world  are 
simply  not  within  reach  or  sight.  In  the  face  of  this 
complexity  the  real-world  business  firm  turns  tc  proce¬ 
dures  that  find  gccd  enough  answers  tc  questions  whose 
best  answers  are  unknowable.  ...  man  is  ...  a  satis- 
ficer,  a  person  whc  accepts  "good  enough"  alternatives, 
act  because  he  prefers  less  to  more  but  because  he  has 
no  choice.  [Bef.  14:  p.  36] 


D.  DESIGN  AS  A  TECHNOLOGIC AL  ACTI7ITI 

Cross  and  others  [Be£.  16]  have  proposed  a  view  of 
design  which  requires  the  explicit  acknowledgement  of  the 
organization's  role  in  design. 

•Technology*  ...  clearly  denotes  more  than  just  hard¬ 
ware,  and  pvojves.  at  the  very  least,  consideration  of 
the  organizational  systems  within  which  machinery  is 
designed,  commissioned,  operated  and  paid  for. 
•Technological'  achievements,  whether  those  of  building 
a  rajcr  bridge  or  cutting  a  man  on  the  moon,  are  as  much 
organizational  feats  as  technical  ones.  [Bef.  16:  p. 


These  ccnsideraticns  lead  to  their  view  that  a  "satis¬ 
factory"  definition  of  technology  has  the  following  charac¬ 
teristics: 

1.  Technology  is  oriented  toward  practical  tasks. 

2.  Technology  relies  on  different  kinds  of  organized 
knowledge,  of  which  scientific  knowledge  is  only  one. 
Craft  knowledge,  design  knowledge,  and  organizational 
and  managerial  skill  are  others. 

3.  Technological  activity  takes  place  in  an  organiza¬ 
tional  context.  [Bef.  16:  p.  198] 

Cross  and  ethers  devote  a  great  deal  of  space  to 
highlight  the  difference  between  knowing  "what  to  do" 
(scientific  knowledge)  and  knowing  "how  to  do"  (design  and 
craft  knowledge) .  Their  main  point  cannot  be  ignored:  the 
organization  plays  as  large  a  role  in  design  as  does  the 
individual. 


E.  DESIGN  IS  EVCLOTICIABY 

The  early  models  of  design  were  frequently  criticized  for 
their  linear,  step-by-step  view  of  design.  Page  (Bef.  11] 
warned  that  the  design  process  is  not  executed  straight  from 
analysis  to  evaluation: 


....in  the  majority  cf  practical  design  situations,  by 
the  tiae  70a  have  produced  this  and  found  out  that  ar.a 
made  a  synthesis,  you  realize  you  have  forgotten  to 
analyze  something  else  here,  and  you  have  to  gc  around 
the  cycle  and  produce  a  modified  synthesis,  and  so  on. 

In  practice,  you  gc  around  several  times. 

Ellinger  stated  that  the  iterative  approach  to  design  "... 
is  pariculazly  suited  to  novel  projects  of  some  complexity." 

[Ref .  12:  p.  vi  ] 

Saithies  [Ref.  17]  has  suggested  that  there  are  a  number 
of  essential  stages  in  design.  The  first  stage,  design 
analysis,  is  the  statement  cf  the  problem,  P.  The  next 
stage  consists  of  finding  one  or  more  tentative  solutions, 
IS.  This  solution  is  then  criticized,  C.  When  the  designer 
criticizes  the  solution,  he  or  she  admits  that  the  problem 
statement  was  inadequate.  So,  the  designer  re-states  the 
problem  and  begins  anew. 

E 1-TS1- C1-P2-. . .  -Pn . 

Saithies  attributes  his  views  about  design  to  Pepper 
[Ref.  18].  popper  believes  that  the  process  or  activity  of 
understanding  can  be  represented  by  a  general  scheme  of 
problem  solving  by  coiec  ture  and  criticism.  Popper's 
scheme,  adapted  by  Stithies,  is  this: 

P1-TT-EE-P2. 

El  is  the  initial  problem  statement;  TT,  the  'tentative 
theory',  is  the  conjecture.  EE,  'error  elimination',  is  the 
critical  examination  of  the  conjecture.  P2  is  the  new 
problem  statement  which  emerges  from  the  examination.  It 
leads  to  another  attempt,  and  so  on  [Ref.  18  :  p.  164]. 

Smithies'  design  stages  and  Popper's  problem-solving  scheme 
are  very  auch  like  Polya's  [Ref.  19]  method  for  solving 
problems.  software  designers  should  take  note:  Polya  is  a 
aatheaatician.  Popper  is  a  philosopher,  and  Smithies  is  an 
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architect,  yet  each  approaches  the  solution  to  a  problem  in 

the  saee  way. 

The  progress  of  the  designer  through  these  stages  is 
marked  ty  increased  knowledge  and  shifting  priorities. 
Clearly  that  progress  is  not  linear  and  should  be  called 
evolutionary. 

f.  S0HB1BT 

Several  points  about  design  have  been  made  in  the 
proceeding  sections: 

1.  Design  is  symmetrical  and  adaptive; 

2.  The  interesting  <i.e.,  large,  complex)  design  problems 
can  be  considered  as  wicked  problems; 

3.  Communications  with  the  end  user  are  crucial  and 
depend  to  a  large  degree  on  patterns  which  bridge  the 
communications  barrier  between  designer  and  end  user; 

4.  Design  is  a  learning  process — each  party  brings  a 
different  perspective  to  the  problem  (and  the  solu¬ 
tion!)  and  leaves  (or  should  leave)  with  an  augmented 
perspective; 

5.  Design  is  satisficing; 

6.  Design  takes  place  in  an  organizational  context; 

7.  Design  is  evolutionary. 

The  separation  of  these  points  should  not  be  miscon¬ 
strued.  Each  cf  these  aspects  is  interrelated  and  to  a 
certain  extent  mutually  dependent  on  one  another.  when  we 
say  that  design  is  evolutionary,  we  also  imply  that  design 
is  symmetrical  and  adaptive.  When  we  say  that  design  is  an 
organizational  activity,  we  also  imply  that  there  will  be 
extensive  communication  during  design.  whenever  we  try  to 
understand  the  problem,  to  learn  mora  about  our  tentative 
solution,  we  are  raising  a  problem  of  understanding,  or 
posing  a  higher  level  problem,  which  implies  that  design 
problems  are  wicked  problems. 
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^kis  interrelated  set  of  design  elements  forms  the  back¬ 
drop  for  the  remainder  of  this  work.  The  following  chapter 
presents  evidence  frcm  the  literature  that  each  of  the 
design  elements  described  above  is  a  factor  in  software 

design. 


III.  SOFTWARE  DESIGH  METHODS 

A.  SOFT8ARE  DESIGN  IS  SYMMETRICAL  AMD  ADAPTIVE 

Several  instances  in  the  literature  point  to  the 
symmetry  cf  the  software  design  problem.  That  is,  the  solu¬ 
tion  not  only  depends  on  the  problem,  but  the  problem 
depends  cn  the  solution.  Solution  and  problem  are  net  sepa¬ 
rate  issues,  rather  they  are  intertwined,  much  like  the 
figure  ar.d  ground  in  a  painting  or  picture.  Each  depends  on 
the  ether.  Unfortunately,  most  people  associated  with  soft¬ 
ware  design  do  net  appreciate  this  point.  Peters  points  cut 
that  software  designers  complain  bitterly  that  requirements 
are  poorly  defined  while  customers  and  analysts  often 
complain  that  the  design  is  not  responsive  to  the  problem  or 
problems  as  they  see  them.  [ Ref .  23  :  p.  67].  Peters 
wasn't  the  first  to  recognize  this,  though.  Podolsky  wrote 
a  humorous  article  in  1977  [Ref.  24]  where  he  states  "Peer's 
Law" : 


Peer*  s  Law 

The  solution  to  a  problem  changes  the  problem. 

Several  ether  authors  [Ref.  25,  26,  and  27]  have  also  recog¬ 
nized  that  the  problem  definition  tends  to  evolve  as  the 
designers  try  to  bound  the  problem,  or  modify  the  require¬ 
ments.  McCracken  and  Jackson  [Ref.  27]  have  gone  so  far  to 
say  that  this  dependence  is  analogous  to  the  Heisenberg 
Principle:  Any  system  development  activity  inevitably 

changes  the  environment  out  of  which  the  need  for  the  system 
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Such  effort  is  currently  devoted  to  requirements  defini¬ 
tion  and  yet  incompleteness ,  ambiguity,  and  poor  definitions 
in  requirements  documents  are  often  pointed  to  as  the'  fore¬ 
most  problems  facing  software  designers  today.  The  effort 
which  is  spent  on  completely  specifying  the  user's  require¬ 
ments  will  gain  nothing  if  software  design  is  adaptive. 

McCracken  and  Jackson  believe  that  systems  requirements 
can  never  be  stated  fully  in  advance.  To  assert  otherwise 
is  to  ignore  the  fact  that  the  development  process  itself 
changes  the  user's  perceptions  of  what  is  possible, 
increases  insights  into  the  applications  environment,  ar.d 
often  changes  the  environment  itself  [Bef.  27:  p.  31]. 
Peters  says  that  although  requirments  may  have  been  very 
fixed  at  the  beginning,  they  tend  to  change  and  evolve  with 
time.  If  for  no  other  reason,  the  user's  perception  of  the 
problem  changes  as  dees  the  designer's  perception  of  that 
problem  [Bef.  23:  p.  70]. 

Change  is  inevitable  during  software  design,  and  yet 
"planning  for  change"  has  long  been  given  lip-service,  at 
best.  Neumann  believes  that  planning  for  change  is  slowly 
being  recognized  as  an  important  end  in  itself — and  one  that 
usually  cannot  be  achieved  by  retrofits  into  an  inflexible 
design  [Bef.  28]. 


B.  DESIGN  IS  SATISFICING 


Most  computer  system  developers  will  immediately  argue 
this  point.  Developers  of  military  systems  would  argue  the 
longest  and  hardest.  Hhy  should  the  idea  of  satisficing  be 
so  controversial?  Perhaps  the  answer  lias  in  the  past,  when 
machine  time  was  expensive  and  computer  memory  limited. 
These  limitations  do  not  exist  at  the  same  level  today.  In 
fact,  satisficing  occurs  all  the  time.  Conn  states  that  the 
requirements  for  state-of-the-art  systems  are  often  scaled 
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down  to  respond  to  the  need  to  cut  the  overall  expense  of 
the  project  or  to  meet  time  limitations  [Bef.  26:  p.  403]. 
Designers  are,  or  should  be,  constantly  aware  of  the  -trade¬ 
offs  that  are  aade  in  systeas  developaent,  especially  the 
classic  trade-off,  ccst  versus  perforaance. 

Several  authors  point  out  that  a  user  should,  in  fact 
■ust,  sacrifice  an  cptiaua  design  for  a  design  which  can 
cope  at  a  satisfactory  level  [Bef.  29,  30].  John  Hunsun  has 
been  quoted  as  saying: 


Users  atst  look  at  the  econoaics  involved  in  automation 
as  a  software- prod uctivit y  solution.  If  a  user  can  buy 
a  payroll  program  that  is  almost  what  he  needs  for 
$10,000  cr  one  that  exactly  fits  his  needs  for  $1 
million,  he  aust  look  at  the  trade-offs  and  reduce  his 
expectations.  [Bef.  30  :  p.  66  ] 


[  Bef. 

30 

:  p. 

66  ] 

has 

to 

do 

with  more 
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Lawrence  Eaters  has  said  that  the  trade-offs  for  execution 
efficiency  and  ease  of  change  aust  be  evaluated  and  a 
compromise  made.  [Bef.  30].  Lockatt  emphasizes  the  role  of 
user  satisfaction  when  evaluating  trade-offs.  For  her,  user 
satisfaction  is  not  based  solely  on  the  functional  capa¬ 
bility  of  a  system,  but  on  useability,  reliability,  and 
performance  as  well.  Often  the  user  cannot  have  everything 
(for  example,  both  performance  and  functional  capability)  he 
cr  she  wants  in  a  system.  The  final  product  may  be  the 
result  of  compromise.  Certain  functional  capabilities  may 
be  eliminated  to  achieve  specific  performance  goals  or,  on 
the  ether  hand,  the  user  may  be  willing  to  sacrifice 
performance  to  obtain  some  functional  capability  [Bef.  31  : 
p.  157]. 

Several  other  authors  emphasize  the  role  of  agreement, 
concensus,  and  negotiation  [Bef.  32,  39,  33].  These  authors 
contend  that  as  system  design  progresses,  alternatives  are 
proposed  and  evaluated.  The  exact  definition  of  a  system 


■ay  net  be  as  important  as  the  concensus  on  the  inexact 
definition  which  is  attained.  An  example  from  Land  serves 
to  illustrate  the  inportance  of  satisficing  in  software 
design: 

....  the  designer  has  to  be  aware  that  building  flex¬ 
ibility  into  systems  can  also  be  expensive,  both  in 
terms  of  design  effort  and  operational  performance.  The 
designer  is  involved  in  a  trade-off  between  the  extra 
development  and  operational  costs  of  designing  a  system 
which  is  adaptable  and  flexible--a  very  general 
system — or  of  designing  a  very  specific  system  dedicated 
to  the  needs  existirg  at  the  time  of  implementation,  but 
which  may  be  incapable  of  modification,  and  may  have  tc 
be  replaced  if  requirements  change.  [Ref.  29  :  p.  67] 

Satisficing  may  also  involve  psychological  trade-offs  as 
well  as  technical  trade-offs.  Madnick  and  Donovan  relate  an 
instance  where  two  possible  algorithms  could  have  b^en  used. 
The  inefficient  algorithm  was  chosen  because  the  designer 
could  not  stand  the  suspense  of  waiting  [Hef.  22:  p.  491]. 

C.  SCFT1ABE  DESIGN  IS  k  NICKED  PEOBLEH 

Hcrst  Rittel  has  suggested  that  design  problems  are 
wicked  problems  [Ref.  13,  9].  These  problems  are  ill- 

formulated,  have  confusing  information,  have  many  clients 
and  decision-makers  with  conflicting  values,  and  have  rami¬ 
fications  in  the  whole  system  which  are  thoroughly 
confusing.  Peters  and  Tripp  have  suggested  that  software 
design  is  a  wicked  problem.  They  believed  that  a  comparison 
of  the  attributes  and  problems  associated  with  software 
design  and  the  characteristics  of  wicked  problems  make  it 
apparent  that  software  design  is  itself  a  wicked  problem 
[Bef.  37],  A  review  of  the  properties  of  wicked  problems 
and  their  relation  tc  software  design  should  help  tc  put 
this  notion  in  perspective. 


Wicked  crob lams  have  no  definitive  formulation .  Any 
time  a  formulation  is  made,  additional  questions  can  be 
asked  and  mere  information  can  be  requested.  Our  inability 
to  define  system  requirements  completely  and  unambiguously 
is  a  symptom  of  this  problem.  Currant  efforts  in  software 
development  seem  to  be  aimed  at  the  symptom  rather  than  the 
problem. 

Several  authors  raise  the  possibility  that  a  complete 
set  cf  requirements  is  impossible,  that  a  stat e-cf-the-art 
system  is  almost  by  definition  one  for  which  there  remains 
some  degree  of  uncertainty  at  the  time  requirements  are 
prepared.  Under  these  conditions,  it  is  hard  to  imagine  a 
set  of  "complete"  requirements,  since  the  knowledge  cf  the 
eventual  system  at  that  point  can  only  be  incomplete 
[Ref.  26  :  p.  403]. 

Wjcked  crobl ems  have  no  stopping  rule.  Any  time  a  solu¬ 
tion  is  formulated,  it  can  be  improved  or  worked  on  more. 
Cne  steps  only  because  one  has  run  out  of  resouces, 
patiencs,  cr  something  else.  Few  would  argua  that  there  are 
clear  stopping  rules  for  software  design.  (Else  why  are 
there  innumerable  examples  of  cost  and  schedule  overruns?) 

Solutions  to  wicked  problems  cannot  be  co rrect  or  false. 
They  can  only  be  goed  or  bad.  This  notion  can  be  quite 
controversial  among  computer  scientists.  Granted,  a 
computer  system  must  work  properly,  especially  in  life- 
critical  cr  life-threatening  circumstances  (hospital  equip- 
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meat  or  nuclear  reactors,  for  example).  But  rtwork  properly" 
has  different  meanings  to  different  people,  or  groups  of 
people,  just  as  do  "correct"  or  "true".3  * 


3Hortimer  J.  Adler  discusses  the  idea  of  "truth",  an 
idea  we  judge  by,  in  Six  Great  Ideas,  aacmilian  Publishing 
Co.,  Inc.,  Sew  fork, 


Perhaps  "good"  and  "baa"  are  poor  choices  as  well,  yet 
■ost  of  us  readily  acknowledge  the  differences  when 
presented  with  "gocd  or  bad,  for  whoa?"  The  distinction 
could  be  thought  of  in  terms  of  'technical  success*  and 
'psychological  success*.  Technical  success  is  the  degree  to 
which  the  actual  performance  of  the  system  matches  its  spec¬ 
ification,  while  psychological  success  is  the  degree  to 

* 

which  the  end  user  has  confidence  in  th**  final  system 
[Bef.  36]. 

Another  distinction  can  be  made  from  the  observer's 
point  of  view  of  a  system:  a  system  exists  and  is  defined 
by  the  perscn(s)  observing  it.  It  is  as  acceptable,  perhaps 
even  laudable,  as  the  observer  perceives  it  to*  be.  If  a 
system  works  in  the  eyes  of  those  who  use  it,  then  to  those 
users  that  system  is  a  good  one.  Conversely,  if  a  system  is 
observed  as  not  working  by  those  same  users,  then  it  is  not 
good  regardless  of  any  ether  attribute  it  may  have. 
[Ref.  33]. 

IS  solving  wicked  problems  there  is  no  exhaustive  list 
of  admissable  operations .  Any  conceivable  plan,  strategy, 
or  act  is  permissable  in  finding  a  solution  and  none  can  be 
prescribed  as  mandatory.  Anyone  in  the  profession  car.  see 
that  this  certainly  applies  to  software  design  (granted, 
there  are  at  present  a  finite  number  of  "design  methodolo¬ 
gies",  yet  each  year  this  number  continues  to  increase). 
The  literature  is  replete  with  references  to  design  method¬ 
ologies:  object-oriented  design,  data-oriented  design, 
design  based  on  finite-state  machines,  and  so  on. 

See  Table  I  for  a  large,  and  certainly  incomplete,  list  of 
design  methodologies. 

Not  only  are  we  faced  with  many  alternatives  for  a 
design  "methodology",  but  we  also  are  faced  with  innumerable 
alternatives  fer  solving  the  subproblems  in  the  particular 
design  case  at  hand.  There  may  be  more  than  one  way  in 
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TABLE  I 

Design  Hethodologies 


aneacnic 

ACH/PCM 

DACES 

DSSAD 

DSSD 

ECU 

GEIS 

HOS 

IBHFSD-SEP 

IESB 

ISAC 

JSC 
NIAH 
S  ACT 
SABA 
SD 

SA-SD 

SDH 

SEFN 

SBEH 

STBADIS 


Fall  Haas  of  Methodology 

Active  and  Passive  Coaponent  Modelling 
Data  Oriented  Design 
Data  Structured  Systems  Analysis  and 
Design 

Data  Structured  Systeas  Development 
Evolutionary  Design  Methodoloqy 
Gradual  Evolution  of  Inforaation  Systems 
Higher  Order  Software 

Adaptation  of  IBH  Federal  Systems  Division 
Software  Engineering  Practices 
Inforaation  Engineering  Specification 
Method 

Inforaation  Systems  (fork  and  Analysis 
of  Changes 

Jackson  System  Development 
Nijssen's  Inforaation  Analysis  Method 
Structured  Analysis  &  Design  Technique 
System  ABchitect's  Apprentice 
System  Developer 

Structured  Analysis  and  Structured  Design 
System  Development  Methodology 
Software  Engineering  Procedures  Notebook 
Software  Requirements  Engineering  Metho¬ 
dology 

STBuctured  Analysis,  Design  and  Implemen¬ 
tation  of  Information  Systems 
Oser  Software  Engineering 


which  a  target  systea  development  process  can  proceed  simply 
because  there  are  alternatie  approaches  available  at  the 
time  the  requirements  are  written.  A  decision  between  these 
alternatives  may  not  be  possible  [Bef.  26  :  p.  403]. 

£c £  ev^ry  wicked  probl ea  there  is  always  more  than  one 
possible  explanation.  The  selection  of  an  explanation 
depends  on  the  perspective,  or  world-view,  used.  The  expla¬ 
nation  also  determines  the  solution  to  the  problem.  (For 
example,  the  high  cost  of  software  is  often  attributed  to 
labor-intensive  design  and  programming;  poor  requirements 
definition  is  often  blamed  for  software  "f ailures” .) 
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N£  wicked  prcblea  and  a2  solution  to  it  has  a  definitive 
test .  In  ether  words,  any  time  any  test  is  "success.f  ully" 
passed  it  is  still  possible  that  the  solution  will  fail  in 
some  other  respect.  This  characteristic  of  wicked  problems 
is  tied  very  closely  to  the  idea  of  satisficing.  If 
coaputer  systems  are  built  to  be  flexible,  their  design  must 
te  generalized.  The  aspect  of  flexibility  is  gained  at  the 
expense  of  efficiency  (not  that  this  is  bad!).  So,  the 
system  "passes”  the  test  for  flexibility  but  is  very  ineffi¬ 
cient. 

Each  wicked  problem  is  a  "one  shot"  operation.  There  is 
no  room  for  trial  and  error  ,  and  there  is  no  possibility  for 
experimentation.  Many  large-scale  computer  systems  have 
this  characteristic.  In  fact,  software  development  is  some¬ 
times  compared  to  building  a  bridge--once  it  is  built  there 
is  no  geing  back  to  the  beginning  to  redesign  and  rebuild  it 
(for  any  number  of  reasons)  . 

Every  wicked  prcblem  is  unique.  Mo  two  problems  are 
exactly  alike  and  no  two  solutions  or  strategies  leading  to 
solution  can  readily  be  copied  for  the  next  problem.  This 
characteristic  is  very  evident  in  software  design.  Military 
systems,  for  example,  are  certainly  unique.  Commercial  or 
industrial  problems  are  no  less  unique.  Each  organization 
has  a  unique  structure,  set  of  goals  and  objectives,  set  of 
interactions  with  the  environment,  cast  of  people,  and  set 
of  needs.4 

The  wicked  crob lea  sol ver  has  no  right  to  be  wrong  — 
he/she  is  fully  responsible  for  his/her  action.  There  has 
been  a  grewing  skepticism  among  users  regarding  the  abili¬ 
ties  cf  software  designers.  Users  have  every  reason  to 
believe  that  the  software  designer  "knows"  the  job. 


♦Note  that  what  is  being  discussed  is  the  overall 
problem,  not  a  subprcblem.  Ths  questions  about  reuseability 
and  software  components  should  be  directed  ONLY  to  subprob- 
leas,  for  obvious  reasons. 
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Clearly,  the  designer  must  be  aware  of  many  of  the  factors 
which  could  affect  the  design.  The  designer  must  also  be 
aware  cf  the  effects  of  design  decisions.  Allowances  will 
and  can  be  made  for  unusual  unforeseen  difficulties.  But  to 
hide  behind  the  "This  system  meets  the  specifications  you 
approved  and  signed"  statement  is  going  (and  has  gone)  too 
far. 

D.  COH HOB IC AT  10 NS  BETBBEN  THE  DESIGNEB  AND  THE  END  OSEB 

Perhaps  the  single,  most  widely  noted  problem  area  in 
software  design  is  the  problem  of  communication  between  the 
user  and  the  designer.  The  recent  literature  emphasizes  the 
need  for  extensive  communications  [Ref.  25,  29,  30,  35,  39, 

and  40].  The  most  common  reason  given  for  the  problem  is 
that  users  and  designers  speak  with  different  vocabularies 
and  find  it  difficult  to  completely  understand  each  ether. 

Much  of  the  literature  which  cites  the  need  fer  closer 
communication  is  based  on  empirical  and  ancedotal  reports. 
King  and  Sodriguez  [  Hef .  41],  however,  report  an  assessment 
of  participation  (and  communication)  in  system  development 
in  an  experimental  context.  The  experiment  tested  feur 
specific  hypotheses  (see  Table  II)  about  participative 
design  which  were  stated  in  null  form.3 

The  experimental  results  (see  table  III)  indicate  that 
participative  design  makes  a  difference,  especially  when 
viewing  the  "worth  of  the  system". 


3This  only  means  that  the  'claim',  i.e..  "accepted 
wisdom"  in  systems  design,  was  set  up  as  the  alternative  to 
the  hypethesis,  in  accord  with  traditional  ay S5th§sis 
testing. 


TABLE  II 

Hypotheses  Tested  in  the  Experiment 


HI:  Participation  in  the  development  of  the  system  has 
no  effect  on  the  user‘s  perception  of  the  worth  of  the 
systes. 

H2:  Participation  in  the  development  of  the  system  has 
no  effect  on  the  amount  of  use  which  is  made  91  the 
system  when  the  user  is  faced  with  strategic  issues  for 
which  the  system  was  designed  to  provide  support. 

H3:  The  substantive  inputs  provided  by  participants  in 
the  design  process  will  not  be  reflected  in  their  usage 
cf  the  system. 

H4:  The  decision  performance  of  participants  in  the 
design  process  will  not  be  different  from  that 
of  non-participants. 


TABLE  III 

Results  of  the  Experiment 


HI:  The  null  hypothesis  is  rejected. 

This  result  indicates  that  managers  who  are  involved  in 
the  development  effort  tend  to  perceive  the  system  to 
be  more  worthwhile  than  managers  who  are  merely  given  a 
pre-designed  system  to  which  they  had  no  input. 

H2:  Cannot  reject  the  null  hypothesis, 
conclude  that  the  use  of  the  system  in  terms  of  number 
of  queries  is  not  significantly  different  for  design 
participants  and  ncn- participants. 

H3:  Ibe  null  hypcthesis  was  rejected. 

it  ipdicates  that  the  substantive  inputs  provided  by  the 
participant  group  in  the  design  and  development  phase 
of  the  information  system  are  reflected  in  their 
actual  use  of  the  system. 

H4 :  Cannot  reject  the  null  hypothesis. 


4s  King  and  Fodriquez  put  it,  the 


....  experiment  provides  some  support  for  "participa¬ 
tive  design  theory":  (a)  The  inputs  provided  by  partic¬ 
ipants  appear  to  have  been  maqle  use  of  in  theip  use  of 
the  system,  and  (t)  some  positive  attitudinal  lmpact-- 
in  terms  of  systems  "worth" — seems  to  be  achieved 
through  participation.  [Ref.  41] 

The  experiment  seems  to  confirm  some  deeply  held  convic¬ 
tions  that  participation  in,  and  responsibility  for,  design 
implementation  can  result  in  elimination  or  reduction  of 
communication  problems  [Ref.  29:  p.  65]. 

There  may  be  seme  reason  to  believe  that  the  real 
problem  with  communication  is  not  whether  it  takes  place  but 
whether  tie  media  of  communication  is  appropriate.  The  fact 
that  the  designer  has  produced  a  comprehensive  specification 
and  that  the  user  has  'signed  off  the  specification  after 
due  study,  is  not  a  guarantee  that  the  designer  has  under¬ 
stood  the  user's  needs,  or  the  user  the  designer's  specifi¬ 
cation  [fief.  29  :  p.  65].  Stuck!  has  suggested  that  charts, 
graphics,  color  pictures,  and  other  aids  should  be  used  to 
enhance  communications  between  users  and  designers;  verbal 
descriptions  alone  are  just  as  inadequate  for  describing 
software  as  they  are  for  an  architect  building  a  house. 
[Ref.  30].  So,  although  communications  may  be  a  significant 
problem,  its  form  may  be  equally  as  important. 

E.  SOFTR4R E  DESIGN  IS  LEARIIHG 

Software  design  is  learning,  just  ask  any  experienced 
program  manager.  They  want  someone  with  design  experience 
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to  head  the  design  team  [Bef.  46].  Without  explicitly 
acknowledging  it,  these  managers  place  value  in  the  experi¬ 
ence  leaded  from  previous  work.  This  ••learning  from 
doing"  also  takes  place  during  the  design  of  a  system: 


The  reason  for  the  discovery  aspects  of  software  design 
is  the  designer's  learning  curve.  As  the  system  is 
studied,  analyzed,  and  a  design  formulated,  certain 
features  are  recognized  as  needing  attention  while 
others  are  overlooked.  As  it  becomes  apparent  which 
features  are  lacking,  priorities  shift.  [Her.  37] 


If  we  accept  that  learning  is  an  element  of  design,  just 
how  important  is  learning  to  design?  In  an  experiment, 
Alavi  and  Henderson  (Bef.  55]  evaluated  two  strategies  for 
systems  development:  evolutionary  and  traditional.  By 
their  definition,  the  evolutionary  strategy  emphasized  the 
role  of  individual  learning.  They  reported  that  the  find¬ 
ings  suFpcrt  the  hypothesis  that  an  evolutionary  implementa¬ 
tion  strategy  is  more  effective  than  a  traditional  strategy 
fBef.  55]. 

They  try  to  explain  their  findings  this  way: 


A  model  which  offers  an  explanation  for  the  findings  is 
Kolfc's  experimental  learning  model  [see  Figure  3.1J. 
Kolfc  suggests  that  for  a  learner  to  be  effective  he^sfie 
must  have  the  ability  to  engage  in  four  types  of  activi¬ 
ties:  (1)  invclveient  in  new,  concrete  experiences,  (2) 
observation  and  reflection  or  rhese  experiences,  (3) 
creation  of  concepts  that  integrate  these  observations 
intc  theories,  ana  (4)  usage  of  these  theories  to  make 
decisions  and  solve  problems.  .  .  .  The  evolutionary 
strategy  maps  directly  with  a  starting  point  at  concrete 
experiences.  In  contrast,  the  traditional  approach 
began  with  the  development  of  a  theory.  ...  An  expla¬ 
nation  of  the  findings  may  rest  in  the  support  that  the 
evolutionary  strategy  had  for  the  learning  process. 
(Bef.  55] 


This  model  has  some  important  implications  for  soft¬ 
ware  design.  For  example,  the  perspective  or  world-view 
that  the  designers  (and  users)  bring  to  a  project  become 
important  (after  all,  we  are  starting  from  concrete 
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Figure  3.1  Kolb's  Learning  Cycle  Model. 

experiences).  Greenspan  and  others  believe  that  the  ability 
to  efficiently  design  appropriate  computer  systems  and 
enable  them  to  evolve  over  their  lifetime  depends  cn  the 
extent  tc  which  real  world  knowledge  can  be  captured 
[Bef.  43].  Wasserman  [Bef.  35]  takes  the  thought  further  by 
suggesting  that  members  of  the  different  groups  ccncerned 
with  design  perceive  the  function  of  an  information  system 
differently.  Misunderstandings  of  objectives  can  and  do 
occur,  many  times  leading  tc  project  failure. 


Land  [Bef.  29]  also  3tates  that  there  are  different 
ideologies  and  perspectives  among  t  h9  different  interests 
involved  in  a  systems  study.  Land  suggests  that  managers 
■eet  this  challenge  by  setting  up  a  design  team  which 
contains  representatives  of  all  the  major  interest  groups, 
making  it  possible  for  the  different  ideologies  and  perspec¬ 
tives  of  the  participants  to  be  aade  explicit,  and  for  the 
different  members  of  the  group  to  learn  iroa  each  others 
different  view ooint s  £Ref.  29], 

Hew  might  the  participation  of  users  in  the  system 
design  enhance  or  promote  learning  and  real-world  knowledge? 
Bobey  [Bef.  42]  conducted  an  experiment  that  explored  a 
model  of  constructive  conflict  in  the  MIS  development 
process.  His  model  (presented  in  Figure  3.2)  is  described 
here : 

User  participation  should  lead  to  conflicts.  which 
should  TFSn“  TSa  satisfactorily  resflTScT.  However, 
conflict  and  its  resolution  are  mff?  ITKely  to  occur 
whan  users  can  exercise  their  influence  in  the  develop¬ 
ment  process.  Conflict  itself  foes  not  lead  to  its 
resolution:  rather  the  increase  in  conflicx  makes  reolu- 
ticn  more  difficult.  It  is  only  through  participation 
and  influence  that  conflict  can  be  successfully  resolved 
in  this  model.  [Bef.  42] 

There  is  other  research  which  supports  Rotey's 

"constructive  conflict".  Boland  [Bef.  54]  compared  two 
different  processes  of  interaction  in  system  design: 

1.  traditional--the  designer  conducts  a  traditional 

interview  of  the  user 

2.  altercative--the  designer  and  user  share  ideas, 

present  mutual  suggestions,  and  critique  their 
suggestions. 

Ris  results  are  significant: 

1.  The  alternative  process  produced  higher  quality 

designs  with  important  implementation  advantages. 
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Pigure  3.2  k  Constructive  Conflict  Hodel  for  User  Involveaent 

2.  The  two  processes  produced  designs  which  used 

different  organizational  control  strategies. 

3.  Different  processes  nay  help  to  define  different 
problens  and  thereby  produce  different,  but  equally 
rational,  solutions.  [Hef.  54] 

Boland  likens  the  problem  solving  process  to  a  dance  during 
which  the  designer  punctuates  his  interaction  with  the  user 


in  a  series  of  teaching ,  suggest ing.  and  critiquing. • 
Eoland  asks  us  to  accept  the  notion  of  learning  and  the 
importance  cf  real  world  knowledge: 

Let  us  accept  that  the  viewpoint  and  implicit  models 
held  tv  designers  will  color  their  collection  and  inter¬ 
pretation  cf  data  about  the  needs  of  the  organization 
they  are  designing  for.  This  study  suggests  tnat  under¬ 
standing  how  that  viewpoint  builds  a  coherent  design 
statement  requires  an  understanding  cf  how  the  designer 
interacts  and  exchanges  information  with  his  client.  The 
interaction  protocols  may  then  be  seen  as  mediating  the 
process  cf  completing  the  designer's  "point  of  view" 
(creating  the  design  statement).  [Ref.  54:  p.  896] 

Robey's  experiment  lends  support  to  Boland's  findings: 
"It  appears  that  participation  does  lead  to  perceived  influ¬ 
ence  in  .  .  .  system  development"  [Ref.  42].  Robey's  find¬ 
ings  suggest  that  influence  is  used  constructively  to 
resolve  conflict  and  that  users  learn  how  to  exert  influ¬ 
ence  towards  conflict  resolution  as  well  as  conflict  genera¬ 
tion  as  the  development  process  proceeds  [Ref.  42  :  p.  82]. 

As  we  have  seen,  there  is  support  that  learning,  argu¬ 
mentation,  and  a  designer's  world-view  are  important 
elements  in  software  design. 

F.  SCFT1 ARE  DESIGN  BAS  AN  ORGANIZATIONAL  CONTEXT 

At  first  glance,  the  casual  reader  is  apt  to  say  "lou 
are  stating  the  obvious."  Yet  much  of  the  current  work  in 
software  design  ignores  the  obvious.  Land  provides  seme 
evidence  for  this: 

1.  Users  are  uncertain  about  the  affect  the  final  system 
will  have  on  their  individual  roles  in  the  organiza¬ 
tion  and  on  them  personally. 


•Compare  Boland's  "dance"  and  Robey's  "constructive 
conflict"  for  software  design  to  Rittel's  "argumentation"  in 
design  (Chapter  II)  . 
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2.  The  observation  that  the  user  operates  within  formal 
systems  and  that  the  formal  procedure  of  the  existing 
systems  have  teen  overtaken  by  less  formal  (but  often 
acre  effective)  unauthorized  procedures. 

3.  The  fact  that  those  who  are  involved  in  the  analysis 
prccess--DP  specialists  and  users— are  often  not 
aware  of  strategic  decisions  made  by  senior  manage- 
ment  which  could  have  an  important  bearing  on  the 
workability  of  the  system. 

4.  New  systems  almost  certainly  include  innovations; 
users  and  analyst/designers  cannot  predict  managers' 
responses  to  innovations.  Conjectures  about  people's 
behavior  are  no  substitute  for  knowledge,  and  in 
innovation,  such  knowledge  is  not  ordinarily  avail¬ 


able.  [ Ref.  29;  p.  64] 

Although  Land  cited  these  points  as  reasons  for  communi¬ 
cations  problems,  they  can  equally  serve  as  indictments 
against  current  software  design.  That  is,  organizational 
aspects  cf  software  design  are  often  ignored. 

Hasserman  points  out  that  organizations  and  computing 
environments  are  highly  dynamic  and  that  information  systems 
must  be  designed  fcr  a  changing  organization  [Ref.  35]. 
Chafin  states  that  as  computer  systems  become  more  deeply 
involved  in  the  operations  of  organizations,  they  have 
larger  social  effects  on  these  organizations.  A  new 
computer  system  may  change  the  organization  structure,  the 
power  structure,  or  the  overall  information  flow  structure 
in  an  organization  [  Hef .  40], 


Zaud  and  Cox  recognized  the  organizational  aspects  of 
software  design  in  their  discussion  of  a  "change'1  approach 
to  design  and  implem entatio n: 

The  change  approach  to  MIS  imple mentation  strives  to 
create  an  environaent  in  which  change  will  be  accepted 
through  the  active  involveaent  of  affected  organiza¬ 
tional  members.  an  intensive  educational  program,  and, 
aost  importantly,  the  assigning  of  project  responsi¬ 
bility  to  the  Mis  user.  Additionally,  a  sense  of  mutual 
trust  and  committment  must  develop  between  participants 
so  that  a  free  exchange  of  beliefs  and  opinions  is 
possible.  [Bef.  53  :  p.  37] 

Zaud  and  Cox  make  no  reference  to  wicked  problems,  yet 
their  change  process  is  recommended  when  (1)  the  organiza¬ 
tional  activity  involved  is  ill-defined,  (2)  the  HIS  must 
interface  with  other  organizational  systems,  and  (3) 
substantial  organizational  change  is  expected.  Compare 
these  characteristics  to  Horst  Bittel's  characteristics  of 
wicked  problems  (Chapter  II). 

Although  there  are  several  articles  and  references  to 
organizational  aspects  of  software  design,  two  authors  stand 
cut.  Kling  and  Scacchi  have  written  two  extansive  articles, 
[Bef.  59  and  60],  which  stress  the  need  for  an  awareness  of 
and  attention  to  organizational  and  social  aspects  of  system 
design.  Their  latest  work  [Bef.  60],  develops  a  family  of 
models  (called  web  mcdels)  which  they  believe  helps  tc  "make 
tetter  predictions  of  the  outcomes  of  using  socially  complex 
computing  developments".  These  models  are  contrasted  to 
'discrete-entity* — rational  and  traditional — models.  Their 
work  attempts  to  abstract  a  set  of  principles, 
characteristic  of  web  models,  from  analyses  published  in  the 
literature. 
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Kling  and  Scacchi  stress  the  importance  of  perspective 
in  the  "social  analyses  of  computing".  They  identify  six 
perspectives,  four  of  which  predominate: 

1.  Formal-rational 

2.  Structural 

3.  Interact  ionist 

4.  Political 

Their  point  in  discussing  these  perspectives  is  that  each 
"casts  a  different  light"  on  the  significant  aspects  of  the 
design  problem.7 

Further  discussion  of  the  work  of  Kling  and  Scacchi  is 
beyond  the  scope  of  this  work.  The  point  to  be  made  of 
their  work  is  that  software  design  is  conducted  in  an  orga¬ 
nizational  framework: 

In  contrast  to  the  discrete-entity  models,  which  gain 
simplicity  by  ignoring  the  social  context  of  computing 
developments,  web  models  make  explicit  the  salient 
conectaons  between  a  focal  technology  and  its  social  and 
political  contexts.  [Bef.  60  :  p.  3] 


G.  SCFTH1BE  DBSIGI  IS  ETOLOTIOBABT 

Much  of  the  current  practice  in  software  design  is 
constrained  by  a  model  popularly  termed  the  •waterfall* 
model.  Tex  Gilb  aptly  sums  up  the  attitudes  of  most  soft¬ 
ware  professionals: 


It  seems  that  they  regognize,  as  yet,  only  one  tyce  of 
life  cycle.  In  particular,  they  seem  to  be  speaking  of 
a  revolutionary  life  cycle  (like  the  birth  or  a  human) 
as  eppesed  to  a  mere  evolutionary  life  cycle  (such  as 
the  development  of  the  human  species).  [Bef.  34  j 


the  _ 
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Cther  authors  also  complain  about  the  current  life  cycle 
model.  Brittan  is  concerned  that  the  serial  definition  of 
the  project  development  cycle,  known  as  the  linear  strategy, 
embodies  cne  fundamental  concept:  that  an  activity  follows 
logically  from  its  predecessor  so  that  each  stage  is 
complete  before  the  next  begins  [Bef.  36].  McCracken  and 
Jackson  seem  to  be  the  most  critical  of  the  current  life 
cycle  model.  They  believe  that  any  fora  cf  life-cycle  is  a 
project  management  structure  imposed  on  system  development. 
Furthermore,  they  point  out  that  the  current  life  cycle 
modal  is  either  a  very  much  simplified  model  (which  is 
worthless)  or  unrealistic  [Bef.  27].  Podolsky  [Bef.  24] 
argues  that  the  current  model  (which  he  terms  'Classic 
Development')  is  "very,  very  good"  when  it  is  successful, 
but  that  when  it  fails,  "it's  horrid".  He  attributes  the 
success  and  failure  cf  Classic  Development  to  the  type  of 
problem  which  will  be  solved:  classic  development  is  good 
for  well-defined,  highly  structured,  change-resistant  prob¬ 
lems;  it  fails  wh9n  presented  with  an  ill-defined  problem, 
changing  participants,  and  changing  requirements. 
Zvegintzov  [Bef.  57]  has  two  objections  to  the  current  life 
cycle  mcdsl.  First,  it  does  not  portray  a  systems  life, 
only  the  creation,  development,  or  youth  of  a  system.  It 
does  not  include  adulthood  and  is  vague  about  operation  and 
maintenance.  Second,  it  is  not  a  cycle,  it  portrays  a 
linear  path  and  does  not,  as  a  cycle  must,  return  tc  its 
beginning  [Bef.  57].  Gladden  even  goes  so  far  to  say  that 
the  software  life  cycle  may  be  harmful  to  the  software 
profession.  See  Figure  3.3  for  Gladden's  representation. 

These  arguments,  and  others,  begin  to  raise  a  question 
about  the  validity  of  the  linear  strategy.  The  linear 
strategy  places  a  great  deal  of  reliance  on  the  studies  and 
efforts  made  in  the  earlier  'stages'  of  software  develop¬ 
ment.  let  this  strategy  ignores  the  fundamental  aspects  of 
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design  described  in  Chapter  II. 
predicament  in  perspective: 


Brittan  places  this 


In  a  majority  cf  cases,  particularly  when  the  organiza¬ 
tion  responsible  for  designing  ana  implementing  the 
system  has  experience  of  similar  systems  and  when  the 
users  are  clear  about  what  taey  want,  the  linear 
strategy  is  pefectly  satisfactory  and  produces  gcod 
regults.  Too  often,  a  project  starts  on  the  linear 
strategy  but  the  initial  requirement  is  vague,  over- 
ambiticus  or  fails  to  meet  the  real  need:  in  fact  the 

Requirement  is  still  fluid.  The  project  then  prcceeds 
in  a  series  of  shcrt  locps  as  the  requirement  solidi¬ 
fies.  .  .  .  [Bef.  36] 


Now  it  becomes  clear  why  Gladden’s  representation  in  Figure 
3.3  appears  as  it  does.  To  make  up  for  the  reality  of  soft¬ 
ware  design,  the  practice  is  to  use  a  'loopy  linear' 
strategy.  That  is,  to  proceed  in  a  series  of  relatively 
haphazard  and  short-term  locps.  Again  from  Brittan: 


of 


Some  loops  are  inevitable.  one  of  the  symptoms  o 
excessive  loopiness  is  a  feeling  of  antipathy  between 
the  different  groups  associated  with  the  project. 


_  _  grcups  _  _ 

particularly  if  they  are  geographically 


^ s 0 cl ( ths 

we/they  syndrome)  :the  svstsm  designers  will  arumble 
about  users  never  fcnowing'what  they  want  and  users  will 
be  anncyed  by  the  apparent  lack  of  good  project  manage¬ 
ment  as  the  system  overruns  its  budget  in  both  time  and 

cost.  [Bef.  36] 


Brittan  gives  other  reasons  why  the  linear  strategy  is  peer: 

1.  when  analysts  refine  the  requirements  of  a  system, 
their  investigations  and  studies  frequently  threw  up 
problems  which  were  not  suspected  at  the  outset. 

2.  the  linear  strategy  can  only  be  based  on  studies  and 
investigations  made  by  analysts;  users,  who  determine 
tfce  success  of  the  system,  are  not  usually  adept  at 
the  conjecture  and  extrapolation  needed  to  understand 
these  studies. 

Land  [Bef.  29],  Brooks  [Bef.  46],  Podolsky  [Bef.  24],  Zave 
[Bef*  32],  and  Lehman  [Bef.  47],  to  name  a  few,  have  all 
argued  that  a  system  will  require  substantial,  continuing 
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changes  after  the  client  begins  to  use  the  system.  Me  tend 
tc  relegate  this  phenomenon  to  •Haintenance* .  But  this 
isn't  enough.  Consider  this  comment  by  Land: 


The  conventional  model  of  the  systems  life  cycle  assumes 
that  an  analysis  and  feasibility  stage  precedes  the 
detailed  design  stage  and  that  this  will  be  followed  by 
a  specification  ana  agreement  of  t{ie  specification  for 
the  system.  it  that  point  the  design  of  the  system  is 
often  frozen.  Por  a  typical  information  system  the 
stages  preceding  the  design  freeze  rake  between  20*  and 
35*  of  the  total  time  required  for  the  develoment  of  the 
system.  Per  between  65*  and  80*  of  this  time  the  design 
of  the  system  is  not  to  be  modified,  even  though  tne 
"world"  is  changing  all  the  time.  In  practice,  even  a 
frozen  design  gets  modified  if  the  system  is  seen  tc  be 
becoming  irrelevant  to  real  requirements.  Purther, 
inconsistencies  in  design  are  discovered  during  the 
construction  phase  as  a  result  of  "systems  queries". 
[Hef.  29  :  p.  68  J 


Software  design,  no  matter  how  hard  we  try  otherwise,  is 
simply  net  linear.  The  literature  clearly  supports  an 
evolutionary  strategy,  yet  our  practice  has  not  recognized 
this. 


H.  SUMH1BY 


The  pxeceeding  discussion  shows  that  there  is  support  in 
the  literature  for  reassessing  our  view  of  software  design. 
Software  design  is  symmetrical,  but  we  currently  do  little 
to  recognize  that  symmetry.  Software  design  is  satisficing, 
yet  there  is  constant  emphasis  on  optimization,  often  for 
its  cwn  sake  and  forsaking  approaches  that  enhance  the 
useability  cr  quality  of  the  software.  Perhaps,  without 
consciously  noting  it,  we  are  also  concerned  with  the  "test" 
design  and  dooming  the  project  to  mediocrity,  at  best,  and 
perhaps  catastrophe. 

Software  design,  especially  for  large-scale  systems,  is 
certainly  a  "wicked  problem."  All  the  evidence  is  there;  it 
only  remains  to  acknowledge  that  fact.  Me  are  well  aware 
that  communications  between  the  designer  and  user  are 


all- important.  Yet,  we  have  not  really  given  much  thought 
to  the  medium  of  exchange.  Software  design  is  a  learning 
experience.  Designers  learn  that  projects  are  more  complex 
than  expected  and  users  learn  never  to  trust  designers. 
This  iay  he  a  harsh  critique,  but  the  point  is  well  illus¬ 
trated:  all  parties  gain  something  from  the  experience  of 
software  design.  Let  us  recognize  the  worth  of  this. 

The  organizational  context  of  software  design  has  long 
been  ignored,  particularly  in  ailitary  systems.  Ha  must  not 
forget  that  the  computers  are  to  help  the  people  in  a  system 
to  fiejfcrm  well,  not  to  control  the  people  as  a  part  of  the 
system.  Finally,  we  are  beginning  to  recognize  that  soft¬ 
ware  design  is  evolutionary.  There  really  is  no  "end"  to  a 
project,  simply  a  restatement  of  the  goals  originally  iden¬ 
tified. 

although  seven  characteristics  have  been  stated  and 
discussed,  their  interdependencies  are  obvious.  None  of 
these  characteristics  is  mutually  exclusive  of  another. 
Rather,  each  builds  on  the  ether,  although  there  are  innum¬ 
erable  implications  in  that  statement,  the  remainder  of  this 
work  will  examine  one  approach  which  may  help  us  to  consider 
the  seven  characteristics  of  design  in  software  design. 


If.  THE  SO FT! A BE  PHOTOTYPE 


A.  ISTBCEOCTION 

For  the  last  35  years,  systems  software  development  has 
teen  based  cn  the  so-called  'system  development  cycle.'  As 
shown  in  the  last  chapter,  there  are  several  arguments 
against  such  a  cycle.  Perhaps  the  most  railing  argument 
lies  in  cur  process  controls.  Several  authors  [Ref.  61  , 
62]  have  pointed  out  that  in  response  ro  uncertainty  and 
increased  complexity,  there  is  a  tendency  to  define  and 
structure  (and  increase!)  management  controls. 

Correspondingly,  precise  requirements  definitions  have  been 
emphasized.  Berrisford  and  Hetherbe  [Ref.  61]  believe  that 
there  is  a  major  conceptual  flaw  in  the  traditional  view  of 
systems  development.  This  is  that  system  design  assumes 
that  management  knows  what  information  is  needed  and  it  is 
difficult,  if  ncr  unrealistic,  ro  ask  managers  to  define 
their  information  requirements  on  paper. 

Hew  dc  software  designers  cope  with  this  problem?  Rich 
and  Haters  [Ref.  63]  have  explored  this  question  and 
theorize  that  software  designers  cope  with  complex  design 
problems  by  using  several  mental  tools,  one  of  which 
involves  simplifying  assumptions.  The  use  of  simplifying 
assumptions  is  both  necessary  and  commonly  used  when 
constructing  large  and  complex  systems: 

Given  a  complex  programming  problem,  expert  programmers 
typically  choose  simplifying  assumptions  which,  thouah 
false,  allow  them  to  arrive  rapidly  at  a  program  which 
addresses  the  important  features  of  the  problem  without 
beina  distracted  by  all  of  its  details.  The  simplifying 
assumptions  are  then  incrementally  detracted  with  corre¬ 
sponding  modifications  to  the  initial  program.  Often 
the  main  questions  can  be  answered  using  only  the 
initial  program.  [Ref.  63  :  p.  150] 


This  use  of  simplifying  assumptions  in  software  design 
is  very  much  like  the  idea  cf  the  tentative  solution,  .  which 
was  introduced  in  Chapter  II.  Such  a  tentative  solution  is 
only  a  simplified  system.  Earl  [Ref.  64]  calls  these 
simplified  systems  prototypes.  Carrying  this  one  step 
farther,  Naumann  and  Jenkins  define  a  prototype  system  as 
"a  system  that  captures  the  essential  features  of  a  later 
system.*'  [Bef.  62].  The  sections  which  follow  will 
describe  the  prototype  process,  the  role  of  prototypes  as 
models,  the  ways  in  which  prototypes  are  used  and  concludes 
by  showing  how  the  set  of  seven  desing  elements  are 
supported  by  software  prototypes. 

B.  TBE  PHOTOTYPE  PROCESS 

The  terms  prototype  and  prototype  systems  have  become 
rather  common  lately,  found  in  both  the  management  litera¬ 
ture  ^Harvard  Business  Review,  for  example)  and  the  software 
engineering  literature  (proceedings  of  conferences  and  work¬ 
shops  especially).  Although  the  term  prototype  has  become 
standard,  early  descriptions  of  the  process  were  called 
"heuristic  development"  and  "iterative  enhancement" 
(Hef.  61,  65]. 

Regardless  of  how  each  of  us  may  use  the  term,  there  is 
general  agreement  that  the  main  purpose  of  prototype  systems 
is  exploration  and  experimentation;  "the  aim  of  the  early 
prototype  is  to  learn,  to  find  out,  to  discover."  [Ref.  68, 
64,  66].  In  keeping  with  their  purpose,  prototypes  are 
relatively  inexpensive,  flexible,  and  simplified  systems. 
Bally,  Brittan,  and  Wagner  describe  the  prototype  process; 

In  the  prototype  strategy,  an  initial  and  usually  highly 
simplified  prototype  verson  of  the  system  is  designed, 
implemented,  tested  and  brought  into  operation.  Based 
on  the  experience  gained  in  the  operation  of  the  first 
prototype,  a  revised  requirment  is  established,  and  a 
second  prototype  designed  and  implemented.  The  cycle  is 
repeated  as  cften  as  is  necessary  to  achieve  a 
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satisfactory  operational  system.  bearing  in  mind  the 
possibly  escalating  cost  or  each  subsequent  cycle;  it 
may  well  be  that  orly  one  prototype  is  necessary  before 
producing  the  final  system.  [Bef.  68:  p.  23] 

Frcm  this  description,  four  steps  are  evident  [Bef.  62]: 

1.  Identify  the  user's  basic  information  requirements. 

2.  Develop  a  working  prototype. 

3.  Iiplement  and  use  the  prototype. 

4.  Revise  and  enhance  the  prototype. 

Figure  4.1  illustrates  the  prototype  process. 

&  prototype  system  must  be  implemented  quic,."  ,  perhaps 
in  hours  or  days,  certainly  no  more  than  two  or  three  weeks. 
The  advantage  here  is  in  the  user-designer  interactions: 
the  user  is  given  a  working  system  to  operate  and  criticize, 
the  designer  receives  responses  based  on  the  user's  experi¬ 
ences.  The  quick  response  of  the  designer  guarantees  that 
the  first  prototype  will  be  incomplete.  This  aspect  is 
important:  there  is  an  explicit  understanding  between  the 

user  and  designer  that  the  system  will  be  incomplete,  that 
a  prototype  is  meant  to  be  modified,  expanded,  supplemented, 
or  supplanted  [  Hef .  62]. 

C.  PBOTCTIPES  AS  HOEELS 

Many  authors  consider  prototypes  to  be  models  [Hef.  64, 
82,  69].  As  models,  prototypes  reduce  risk  and  test  alter¬ 
native  designs  through  live  operation.  [Bef.  64], 

Three  aspects  of  prototypes  as  models  are  important. 
First,  models  are  abstract: 

The  critical  skill  cf  system  design  is  .  .  ,  claimed  tc 
be  explication  of  tfc®  implicit  models  in  managers' 
minds,  of  their  decision-making  processes  and  views  cf 
their  organisation  and  environment.  [Bef.  64  :  p.  163] 
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Pigure  4.1  The  Prototype  Bodel. 


Second,  managers  prefer  simple  models  at  first.  As  they 
begin  to  understand  the  models,  they  become  involved  with 
the  design  and  implementation  to  build  more  realistic 
systems.  [  Bef .  64]. 

Third,  a  prototype  is  subject  to  modelling  effects. 
That  is,  as  a  model,  the  prototype  is  only  a  limited  version 
of  the  final  system.  So,  a  prototype  is  one  kind  of  scale 
model ,  accurate  in  some  ways,  inaccurate  in  others 

(Bef.  691. 


0.  STRATEGIES  TO  PRODUCE  PROTOTYPES 


Three  strategies  are  generally  recognized  for  producing 
prototypes,  1)  methodologies  (in  current  use)  ,  2)  executable 
specifications  (state-of-the-art  and  research  issues)  ,  and 
3)  automatic  programming  (a  research  topic) . 

1 •  Ike  Methodology 1  strategy 

There  are  three  basic  methodologies  which  are  used 
to  produce  software  prototypes.  First,  in  screen  and  report 
formatting,  the  designer  produces  a  set  of  user  interfaces 
which  will  be  similar  to  the  final  system.  Second,  in 
partial  ard  incomplete  implementation,  the  designer  and  user 
identify  only  a  subset  of  the  total  problem.  Third,  for 
selective  implementation,  the  designer  develops  components 
of  tte  final  system  and  then  integrate  the  components. 
[Ref.  71] 

2 •  executable  SEeci fications 

The  executable  specification,  the  second  technique 
for  prototyping,  is  a  current  ’hot'  topic  in  the  computer 
science  literature.  Davis  [Ref.  72]  describes  a  software 
tool,  the  Feature  Simulator,  which  "executes"  formally 
writter  requirements  specifications  for  real-time  systems. 
Feather  [Ref.  73]  proposes  a  methodology  for  developing 
prototypes  from  specifications  based  on  the  transformation 
of  "specification  constructs"  into  an  implementation. 
Perhaps  the  most  ambitious  work  on  executable  specifications 
is  that  reported  by  Cohen  and  others.  They  believe  that  "a 
prototype  serves  to  micxgate  both  imperfect  communication 
and  lack  cf  forsight  (sic)."  [Ref.  74] 

The  solution  Cchen  and  others  have  adopted  separates 
the  imperfect  communication  and  lack  of  foresight  issues  by 
having  a  formal  specification  language  which  unambigicusly 
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describes  systems,  and  a  separate  tool  (symbolic  execution 
system)  which  helps  the  reader  to  understand  any  particular 
specification.  This  tool  can  be  used  by  the  specification 
writer  tc  validate  the  specification  and  by  the  implementor 
(or  buyer)  to  understand  what  exactly  has  been  specified 
(i.e.,  hew  the  pieces  interact).  "Given  the  specification 
and  the  tool,  a  prototype  will  not  be  needed."  That  is,  if 
the  designers  can  completely  specify  the  requirements  and 
they  then  use  the  symbolic  execution  system,  Cohen  and 
others  believe  that  it  is  no  longer  useful  to  develop  a 
prototype . 

Eut  consider  the  following  comment  by  Taylor  and 
Standish : 


....  having  a  precise  specification  language  is  of  no 
help,  since  the  user  really  doesn't  know  what  statements 
to  make  in  such  a  language —  that  is,  he  can't  articu¬ 
late  his  needs  if  he  doesn't  know  what  they  are  reaard- 
less  of  whether  or  not  there  is  a  precise  language  for 
stating  them.  [Hef.  78  :  p.  160] 


Executable  specifications  clearly  are  controversial, 
especially  when  they  concern  prototypes.  whether  such  a 
technique  gains  prominence  will  depend  on  advances  in  soft¬ 
ware  engineering  tools. 

3.  Autcma t ic  Programming 

Automatic  programming  is  probably  farther  away, 
technically,  than  the  exacutable  specification.  Automatic 
programming  can  be  thought  of  as  programs  that  help  people 
write  programs.  The  general  goal  of  automatic  programming 
is  tc  allow  the  software  designer  to  think  of  the  problem 
abstractly,  in  a  way  which  is  natural  and  comfortable. 
Automatic  programming  systems  are  characterized  by  specifi¬ 
cation  methods  (formal,  'by  example',  or  natural  language), 
the  target  language  (the  language  in  which  the  system  writes 


the  finished  program) ,  the  problem  area  (area  of  intended 
application)  ,  and  the  method  of  operation  (theorem- proving, 
program  transformation,  knowledge-engineering,  or  tradi¬ 
tional  problem  solving)  [Ref.  100].  One  advantage  of  auto¬ 
matic  programming  is  that  it  could  allow  for  more 
informality  than  an  executable  specification  language 
[Ref.  70]. 


E.  OSES  CP  PROTOTYPES 

Generally,  there  are  three  uses  of  prototypes,  1)  to 
clarify  user  requirements,  2)  to  verify  the  feasibility  of  a 
design,  and  3)  to  create  a  final  system.  [Ref.  75]. 

1  •  Clarify  th£  Oser  's  Requirements 

Ey  far,  the  most  popular  use  of  prototypes  is  to 
clarify  the  user's  requirements.  McCracken  [Ref.  67] 
believes  that  traditional  written  specifications  do  not 
bridge  the  communications  gap  between  the  designer  and  the 
user.  He  states  that  prototypes  encourage  users  to  change 
their  mind'  about  what  they  want,  until  the  system  is 
useful. 

Tc  highlight  the  problems  encountered  in  require¬ 
ments  documentation.  Mason  and  Carey  [Ref.  76]  make  a 
distinction  among  three  types  of  documentation: 

1.  A  textual  list  of  requirements  (the  most  commonly 
used) 

2.  An  interpretive  model  (gaining  in  popularity,  espe¬ 
cially  in  military  systems) 

3.  A  working  model — a  prototype 

The  textual  list,  the  traditional  method  of 
describing  requirements,  has  a  distinct  disadvantage.  There 
is  a  psychological  distance  between  a  textual  list  and  what 
the  users  wili  eventually  receive.  A  lengthy  (often  boring) 


document  does  not  easily  convey  a  realistic  sense  of  hew  the 
system  will  operate  and  suit  the  user's  needs  [Ref.  76-]. 

Interpretive  models  include  SADT  and  USE.  These 
models  use  top-down  decomposition  to  manage  the  complexity 
cf  large  systems.  The  more  detailed  these  tools  are  (or 
become)  ,  the  more  specialized  the  language  used.  This  pres¬ 
ents  a  significant  learning  burden  to  the  user  [Ref.  76]. 

Prototypes,  cn  the  ether  hand,  present  a  more  real¬ 
istic  view  cf  the  system  to  the  users.  The  users  can  easily 
relate  their  experience  with  the  prototype  to  their 
requirements. 

2.  To  Verify  the  Feasibility  of  Design 

When  prototypes  are  used  to  verify  the  feasibility 
of  a  design,  the  designers  and  users  are  evaluating  the 
internal  design  of  the  software  [Ref.  75].  After  the  proto¬ 
type  is  developed,  several  aspects  of  the  design  could  be 
evaluated:  the  prototype  could  be  used  to  implement  and 
evaluate  certain  design  decisions;  the  prototype  could  be 
used  to  develop  and  test  a  production  system;  the  efficiency 
of  the  prototype  could  be  examined;  or  the  prototype  could 
be  developed  on  one  machine,  and  the  final  system  imple¬ 
mented  cn  the  target  (or  production)  machine,  when  it 
becomes  available. 

3 .  Tc  Create  the  Final  System 

Prototypes  may  be  used  to  create  the  final  system. 
This  means  that  part  or  all  of  the  final  version  of  the 
prototype  may  beccme  part  of  the  production  system 
[Ref.  75].  Examples  of  this  technique  might  include  data¬ 
base  managenment  system  (DBAS)  applications.  For  example, 
once  created,  the  prototype  might  remain  unchanged  espe¬ 
cially  if  the  system  efficiency  is  satisfactory.  On  the 
other  hand,  critical  (or  perhaps  all)  of  the  system  woula  be 


recoded  tor  efficiency,  either  in  the  DBMS  language,  in  a 
host  language,  or  in  assembly  language. 

P.  PB0TCT1PES  ADDRESS  THE  ESSE1TI1L  DESIGH  ELEMENTS 

1 •  Prototyping  is  a  Sv  mmetrical  and  Adaptable  Process 

Prototypes  explicitly  address  the  symmetry  and  adap¬ 
tation  necessary  in  software  design.  Naumann  and  Jenkins 
(Ref.  62]  believe  that  prototypes  provide  an  appropriate 
response  to  changes  in  the  development  process  (problems  to 
solve  and  available  resources)  as  well  as  to  changes  in  the 
environment .  Bally,  Brittan,  and  Magrsr  state  that  the 
prototype  strategy  is  an  admission  of  failure,  an  admission 
that  there  will  be  circumstances  when  we  will  be  unable  to 
develop  the  right  system  on  the  first  attempt  [Ref.  68]. 
Earl’s  comment  perhaps  best  expresses  the  overall  idea  of 
symmetry  and  adaptation: 

The  prototype  system  .  .  .  allows  .  .  .  design  by 

discovery  as  much  as  by  prediction,  where  t he  unexpected 
results'  may  be  as  significant  for  design  as  the 
expected.  (emphasis  added)  ( Bef .  64  :  p.  166]. 

2.  Prototyping  'Tames1  the  Wicked  Problem 

In  Chapter  II  wicked  problems  were  described  as 
problems  where  the  information  is  confusing,  where  there  are 
many  clients  with  conflicting  values,  and  where  the  ramifi¬ 
cations  in  the  whcle  system  are  thorougly  confusing. 
Compare  those  characteristics  to  the  experiences  cf  Asnar 
and  King: 


.  .  .  .  the  prototype  approach  works  when  users  do  not 

know  their  specific  requirements,  [where]  the  effective¬ 
ness  of  any  on  particular  approach  cannot  be  easily 
assessed  without  real-life  experience,  .  .  .  [where] 

the  system  will  be  an  integral  part  of  the  day-to-day 
activities  of  the  users.  .  .  .  [Ref.  79  :  p.  30] 
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Developing  prototypes  does  more  than  recognize 
wicked  problems.  The  designers  and  users  of  prototypes 
explicitly  acknowledge  such  things  as: 

1.  Wicked  problems  have  no  definitive  solution--as  Eally 
and  others  have  stated,  prototypes  are  an  admission 
that  mors  questions  can  be  always  asked  and  more 
information  can  be  requested. 

2.  Every  formulation  of  the  wicked  problem  corresponds 
to  the  formulation  of  the  solution  (and  vice 
versa)  —  there  is  an  explicit  understanding  between 
the  desinger  and  user  about  basic  assumptions  that 
will  be  made  when  designing  a  prototype,  especially 
the  first  version;  the  protcype  strategy  is  designed 
to  ccpe  with  a  fluid  situation  and  fuzzy  requirements 
[fief.  68]. 

3.  Wicked  problems  have  no  stopping  rule — designers  and 
users  realize  that  prototypes  may  be  continually 
modified  or  refined  until  some  external  limit  (time, 
resources,  production  need,  user  satisfaction,  etc.) 
is  reached. 

4.  Solutions  to  wicked  problems  cannot  be  correct  or 
false.  They  can  only  be  good  or  bad — prototyping 
explicitly  recognizes  the  notions  of  "technically" 
correct  and  "psychologically"  correct.  Users  contin¬ 
ually  ask  for  refinements  until  they  become  satisfied 
(i.e.,  where  the  system  is  technically  and  psycho¬ 
logically  correct) . 

5.  In  solving  wicked  problems  there  is  no  exhaustive 
list  of  adnissable  operations--pro totypes  allow 
designers  and  users  the  freedom  to  explore  and  exper¬ 
iment. 

No  wicked  problem  and  no  solution  to  it  has  a  defini¬ 
tive  test —  designers  and  users  become  quickly  aware 
that  prototypes  clearly  identify  tradeoffs.  The 
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prototype  aay  be  flexible  and  sacrifice  (i.e.,  "fail" 
the  test  for)  efficiency. 

3.  Software  Prototyping  is  Satisficing 

Becall  from  chapter  II  Siaon's  argument  that  people 
accept  alternatives  which  are  good  enough,  not  because  they 
want  to,  tut  because  they  have  no  choice.  In  Chapter  III 
evidence  was  presented  which  clearly  shows  that  software 
designers  constantly  balance  trade-offs  and  are  forced  to 
accept  satisfactory  alternatives,  rather  than  an  optimal 
alternative. 

The  process  of  developing  a  prototype  explicitly 
deals  with  satisficing  by  recognizing  the  interaction  among 
the  user,  designer,  and  system.  Conflicting  goals  and 
priorities  are  inevitable.  Negotiation  between  the  designer 
and  user  will  lead  to  a  satisfactory  system. 

In  the  prototyping  process,  the  designer  constructs 
successive  versions  of  the  system,  compromising  and 
resolving  conflicts  between  the  context  (that  is,  user  needs 
and  desires)  and  the  form,  as  constrained  by  technology  and 
economics  (Bef.  62  :  p.  37]. 

4.  Prototyping  is  Communicating 

The  prototype  facilitates  communication  between  the 
designer  and  the  useri  The  basic  model  of  the  prctoype 
process  shows  that  communication  is  a  necessary  element  of 
the  process.  Without  communication  there  is  no  prototype. 
Nason  and  Cary  [Bef.  76]  believe  that  prototyping  overcomes 
the  fundamental  problems  of  communication  between  users  and 
designers.  Naumann  and  Jenkins  [Bef.  62]  emphasize  the 
roles  participants  have  and  believe  that  prototyping 
stresses  the  interactions  between  the  user  and  the  designer. 


Participator  in  software  design  can  be  painful 


[Ref.  64],  yet 


Users  Flay  nore  active  roles  in  prototyping  than  is 
possible  with  traditional  development  methods.  Users 
set  the  development  pace  by  the  time  they  spend  using 
and  evaluating  the  prototype.  They  decide  when  the 
cycle  of  evaluation  and  refinement  ends.  [Ref.  62  :  p. 


The  prototype  approach  exploits  the  interaction 
between  the  designer  and  user.  Contrast  this  with  the  care¬ 
fully  monitored  interaction  in  the  traditional  approach. 

5.  The  Software  Prototype  is  a  Learning  Aid 

Several  authors  [Ref.  64,  68,  66]  agree  that  the 
very  purpose  of  the  prototype  is  to  allow  the  user  to  learn 
about  the  system;  experience  with  the  system  is  the  most 
valuable  product.  When  prototyping,  both  designers  and 
users  learn,  developing  a  system  which  is  more  realistic  in 
its  economic  purpose,  organizational  context,  and  technical 
performance  [Ref.  64  :  p.  166]. 

Earl  [Ref.  64]  believes  that  prototype  systems 
permit  action  learning  and  that  there  are  few  other  vehicles 
available  for  live  and  flexible  organizational  development. 
As  a  vehicle  for  learning, 

....  the  protoype  model  is  the  most  effective  repre¬ 
sentation  possible  since  it  enables  evaluation  of  the 
proposed  design  in  context.  The  prototype  model  is  the 

fepresentation  tEat  anticipates  evaluation  of  the  design 
n  its  operating  environment.  [Ref.  62  :  p.  33] 
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6.  T£g  Prototype  Processs  Accounts  for  Organizational 

Issues 

As  pointed  out  in  Chapter  III,  the  organizaitcnal 
context  is  an  important  consideration  in  systems  and  soft¬ 
ware  desicn.  Infernal  organizational  structures  and  the 
sub-sleaents  of  organizations  play  large  roles  in  the 
success  cr  failure  cf  a  system.  As  an  experinent,  the 
prototype  provides  an  opportunity  to  test  the  impact  of  a 
system  and  experiment  on  the  organization's  interfaces,  at 
least  reducing  the  risk  of  a  nonviable  system  and  also 
providing  epport unities  for  introducing  and  monitoring  job 
satisfaction  improvements,  organization  development,  and  the 
like  [Hef.  64:  p.  164].  Earl  believes  that  prototypes  are 
relevant  to  organizations  because  of  individual  differences 
among  people  in  the  organization: 


options  may  not  be  apparent.  with  a  working  prototype 
system  design  values  may  be  explicated  and  stakeholders 
counter  the  technical  thrust  of  the  specialists.  . 

[Hef.  64  :  p.  165] 

To  say  that  prototyping  "solves"  the  organizational 
issues  in  software  design  is,  however,  going  too  far. 
Prototyping  deals  explicitly  with  the  issues,  yet  requires 
quite  a  tit  of  "orchestration".  The  management  of  the 
process  is  not  without  political  consequences  [Ref.  66]. 

Hew  do  we  measure  the  worth  of  a  prototype  as  it 
contributes  to  our  design  cf  software?  Earl  answers  this 
guestion  with  the  following  statement: 


use  and  organisational  learning.  [Hef.  64  :  p.  166] 


7 .  The  Prototype  Process  is  Evolutionary 


That  the  process  of  protoyping  is  incremental  and 
evoluticnary  shold  ccme  as  no  surprise.  The  important  point 
is  that  the  prototype  process,  again,  explicitly  deals  with 
the  issue.  Software  design  has  been  shown  to  be  evolu¬ 
tionary,  yet  traditional  software  development  is  unable  to 
deal  with  it.  Naumann  and  Jenkins  [Eef.  62]  state,  as  a 
•principle',  that  "[prototyping  represents  and  parallels 
the  dynamic  process  of  growth,  change,  and  evolution 
existing  in  any  living  system." 

A  survey  of  the  literature  reveals  an  interesting 
pattern  among  the  models  for  prototyping.  Although  most 
authors  will  agree  that  the  traditional  life  cycle  is  not 
evolutionary,  with  the  exception  of  Naumann  and  Jenkins 
(Ref.  62],  (see  also  figure  4.1)  Basili  [Ref.  65],  Bally  and 
others  [Ref.  68],  Earl  [Ref.  64],  Nason  and  Carey  [Ref.  76], 
and  Zvegintzov  [Ref.  57]  all  attempt  to  force  a  c vc lie 
structure  on  software  development. 

Perhaps  a  review  of  evolution  is  in  order.  when 
some  thing  (animal,  erganizaiton,  or  design)  evolves,  it 
begins  simply  (a  few  cells,  a  few  people,  a  few  details  and 
many  simplifying  assumptions)  and  grows  in  complexity,  often 
changing  remarkably  from  its  humble  beginnings.  This 

process  is  clearly  act  cyclic.  Rather,  a  better  image  is 
the  spiral,  much  like  the  spiral  coil  of  the  shell  of  the 
Nautilus,  growing  in  size  yet  maintaining  the  essential 
nature  it  began  with. 

Figure  4.2  illustrates  the  evolutionary  nature  of 
prototypes.  Each  "chamber"  can  be  considered  to  be  a  single 
prototype,  the  wall  of  the  "chamber"  denoting  the  point  of 
refinement  and  enhancement.  The  only  restrictions  on  the 
number  of  "chambers"  (prototypes)  are  in  the  environment 
(exhausted  resources,  end  of  time,  too  complex  or  unwieldy, 
and  sc  on) . 
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Figure  4.2  Evolution  of  Prototypes. 


6.  SUMMABY  AND  IHTESMEDIAT E  COBCLUSIOBS 

This  chapter  has  explored  the  multi-f aceted  aspect  of 
the  software  prototype:  the  process,  its  role  as  a  model, 
construction  strategies,  and  uses.  The  chapter  concludes 
with  a  persuasive  argument  that  prototypes  explicitly 
support  the  seven  design  elements. 


Several  conclusions  can  be  stated  at  this  time.  First, 
the  current  practice  cf  software  engineering  only  recognizes 
a  few  cf  the  design  elements  described  in  Chapter  II. 
Software  design  completely  ignores  the  fact  that  these 
elements  are  interrelated  and  mutually  dependent.  The 
traditional  method  of  software  development  only  worsens  the 
problem . 

Second,  the  prototype  approach  to  software  design  and 
development  naturallj  supports  the  set  of  design  elements. 
For  example,  the  prototype  approach  encourages,  reguires, 
and  exploits  the  interaction  and  communication  between  the 
user  and  designer.  Ey  making  this  explicit,  prototypes  will 
lead  to  a  better  design. 

Third,  developing  better  systems,  delivering  them  on 
time  and  within  budgets  are  in  our  best  interests.  The 
prototype  approach  will  allow  software  engineers  and 
designers  to  achieve  these  goals. 

The  next  chapter  briefly  describes  software  engineering 
environments  and  how  such  an  environment  could  and  should 
support  software  prototyping. 


T.  THE  SOFTNABE  BBGUBBBIHG  BHVIBOHMEKT 


A.  INTRODUCTION 

Host  authors  agree  that  prototyping  has  become  possible 
through  recent  developments  in  computer  technology  [Bef.  61, 
62].  Collectively,  this  technology  is  called  the  software 
engineering  environment  (SE2)  [Bef.  83],  the  programming 
support  environment  [Bef.  107,  105],  or  the  software  devel¬ 
opment  environment  [  Ref.  84  ]. 

There  are  as  many  definitions  for,  as  there  are 
references  to,  a  software  engineering  environment.  The 
definition  offered  by  Hausen  and  Huellerburg  seems  to  be  the 
most  satisfying: 


[A  Software  Engineering  Environment  is  ]  an  instrumented 
and  organized  software  development  laboratory  where  many 
people  cccperate  .  with  each  other  in  a  fully  organized 
worfcxna  process,  in  the  design,  construction,  examina¬ 
tion,  tuning  and  maintenance  or  software.  [Ref.  83  :  p. 
147].  *  t 


Generally  speaking,  the  literature  cites  two  approaches 
to  computer-aided  design  for  software  development:  1)  the 
SE*  is  a  systematic  approach,  and  2)  toolboxes  or  toolkits 
which  support  specific  software  development  activities 
[Bef.  85].  Ihe  UNIX  development  environment  is  an  excellent 
example  cf  the  toolkit  approach  [Bef.  86].  The  facilities 
of  UNIX  may  be  thought  of  as  a  "tool  kit"  from  which  the 
developer  can  select  tools  that  are  appropriate  fer  a 
specific  task.  Detailed  discussions  of  the  UNIX  environment 
and  available  tools  can  be  found  in  [Bef.  87  ,  88]. 

The  toclkit  approach,  however,  has  been  criticized 
because: 
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1.  Tools  are  not  organized  to  support  specific  software 
development  methodologies; 

2.  Teels  do  not  capture  management  or  control  data  for 
seftware  development;  and, 

3.  Individual  tocls  are  largely  uncoordinated  [Bef.  89]. 
Lauber  has  reviewed  11  tool  systems  in  practical  use  and 
finds  that  only  two  systems  (PSL/PSA  and  PDL)  are  in  wide 
use.  • 

There  are  several  "programming"  environments  in  active 
use  (for  example.  Interlisp  [Bef.  90  ,  86  ,  91]  ),  or 

planned  (for  example,  the  Ada  programming  support  environ¬ 
ment  (APSE)  [Bef.  93]  ).  Unfortunately,  there  is  nc  3E2 
which  specifically  supports  the  prototype  process.  This 
chapter  will  first  describe  some  general  characteristics  of 
SE2  s  and  then  explain  those  elements  of  SS2s  which  are 
needed  to  support  software  design  and  prototyping. 

E.  C HA B ACT ERISTICS  Cf  SOFT1ABE  ENGINEERING  ENVIRON HEATS 
1  •  Development  Support  Tasks 

There  is  general  agreement  that  an  SE2  supports 
three  development  "tasks”:  1)  software  production  manage¬ 

ment,  2)  technical  aspects  of  software  development,  and  3) 
user  participation  in  applications  development  [Bef.  83,  94 

,  95].  An  SE2  aids  software  management  by  "capturing" 

information  about  design  decisions  and  the  progress  of  the 
development  itself.  An  SE2  supports  software  development  by 
providing  automated  tools.  During  rhe  development  of 
specific  applications,  the  SE2  places  special  emphasis  on 
the  role  of  user-designer  interaction. 


•Problem  Statement  Language/Problem  Statement  Analyzer 
and  Program  Design  language.  A  detailed  review  of  the 
various  tools  and  environments  in  current  use  can  be  found 
in  S||£csium  on  Software  Engineering  Environments  ,  Huenke, 
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2 .  Integrat  ed 


L  ' 

■ 


An  integrated  SE2  will  support  the  three  development 
tasks  by  unifying  the  tasks  into  an  ensemble.  Integration 
applies  to  the  ease  of  using  and  the  ease  of  documenting 
those  activities  associated  with  individual  tools  [Bef.  84], 
Perhaps  one  of  the  mere  important  characteristics  of  an  SE2f 
integration  makes  it  easier  to  combine  various  tools  in 
order  to  perform  a  specific  function. 

3 .  Onif  cr  m 

A  variety  of  automated  tools  are  used  by  the  SS2  to  support 
the  three  development  tasks.  For  reliable  operation,  the 
tools  must  be  consistent  with  one  another  [Ref.  84,  94  ,  95 
,  96],  If  one  tool  is  consistent  with  the  rest,  the  SE2 
will  be  easier  to  use.  It  is  easier  to  learn  and  use 
special  formats  and  command  structures  when  they  are  consis¬ 
tent  among  all  of  the  tools. 

4 •  Support  a  Solution  Strategy 

The  technical  aspects  of  software  development 
require  the  SE2  to  support  two  solution  strategies,  ere 
general  and  the  ether  specific.  Generally,  Soni  and  others 
believe  that  the  SE2  must  support  different  ways  of  solving 
the  problem.  [Bef.  84].  That  is,  the  SE2  should  support 
many  different  ways  cf  solving  problems.  It  should  be  flex¬ 
ible  enough  any  problem-solving  strategy.  For  the  specific 
strategy,  Wasserman  and  others  believe  that  an  SE2  must 
support  both  the  software  life  cycle  model  (the  'waterfall' 
model)  and  any  particular  software  development  methodology 
which  dees  not  diverge  very  much  from  that  model  [Bef.  94, 
95,  97].  In  either  case,  the  objective  is  the  same:  to 

arrive  at  a  solution. 


5 .  Adaptable 


Fer  practical  reasons,  an  SE2  should  be  adaptable. 
In  most  organizations,  each  of  the  development  tasks  is 
covered  by  different  organizational  groups,  each  wirh  their 
own  styles,  attitudes,  and  so  on.  Also,  the  individuals 
within  each  group  bring  different  perspectives  to  the  job. 
With  such  a  wide  range  of  personalities,  a  collection  of 
tools  should  be  flexible,  changeable,  even  extensible 
[Ref.  84].  The  SE2  should  be  able  to  adapt  to  the  design¬ 
er's  (or  user's)  sophistication  and  should  provide  defaults. 
Defaults  could  be  easily  changed  as  users  become  mere 
sophisticated  [Ref.  94,  95,  96  ]. 

6 •  Functionally  Dnigue 

Within  each  development  task,  there  are  a  number  of 
unique  functions.  To  reduce  ambiguity,  misunderstanding, 
and  errors,  tools  within  an  SE2  oust  be  functionally  unique. 
That  is,  they  must  have  a  singular  purpose  [Ref.  84,  94,  95, 
96].  Each  tool  must  be  limited  to  a  single  design  function. 

7 .  Interactive 

An  SE2  must  have  interactive  system  capabilities. 
[Ref.  85,  84,  94,  95,  98  ].  There  are  two  reasons  for  this: 
interactive  systems  aid  communication  among  the  participants 
in  design,  and  designers  can  work  at  th sir  own  pace  (inter¬ 
actively)  rather  than  someone  else's  (batch).  User  partici¬ 
pation,  one  of  the  development  tasks,  is  simplified  when 
using  interactive  systems. 

8.  Recent  Deve lerments 

Two  ideas  about  SE2s,  personal  development  systems 
and  a  software  engineering  knowledge  base,  seem  to  unify  tne 
three  development  tasks  and  embody  the  characteristics  just 
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stated.  Personal  development  systems  have  all  of  the  char¬ 
acteristics  discussed  (integrated,  uniform,  support  a  solu¬ 
tion  strategy,  adaptable,  functionally  unique,  and 
interactive) .  Their  most  important  feature,  though,  is  the 
dedicated  support  to  a  single  designer  [Ref.  89  ,  94  ,  95]. 

A  software  environment  knowledge  base  would  capture  informa¬ 
tion  about  the  design  activity  (for  example,  design  deci¬ 
sions)  as  well  as  the  development  process  (a  continuous 
effort)  fcr  managers,  designers,  and  users  [Ref.  96].  This 
knowledge  base  would  make  the  information  easily  available 
and  wculd  be  done  autcmatically. 

C.  A  SOFTHAHE  ENGINEERING  ENVIRONMENT  FOB  PROTOTYPES 

Mcst  authors  agree  that  a  'successful'  SB2  must  support 
a  certain  view  of  the  design  process  [Bef.  85,  94,  95,  97]. 

Following  the  lead  of  Lauber  [Bef.  85],  a  collection  of 
tools,  or  components,  which  support  the  set  of  seven  design 
elements  of  Chapters  II  and  III,  and  which  support  the 
development  of  prototypes,  covered  in  chapter  IV,  is 

presented.  This  is  followed  by  descriptions  of  how  such 

components  support  software  design  principles  and  proto¬ 
typing. 

1  •  Technical  Components 

There  are  several  components  which  should  be 
included  in  an  SE2  [Bef.  62,  75,  79,  83,  101]. 

a.  Database  Management  Systems  (DBMS) 

A  DBMS  serves  two  purposes  in  an  SE2.  First, 

the  DBMS  enables  storing  and  retrieving  information  about 

the  design  as  well  as  the  development  process.  For  example, 
a  record  could  be  kept  of  when  each  version  of  the  prototype 
was  released,  who  designed  it,  relevant  design  decisions. 


and  so  on.  Second,  a  DBMS  allows  for  ‘quick*  design  and 
programing  of  data  handling  features  [Ref.  62,  61,  83]. 

Becall  that  the  ability  for  quick  turnaround  of  a  working 
systea  to  the  user  is  a  necessary  feature  in  many  proto¬ 
typing  situations. 

b.  Generalized  Input  and  Output  Software 

Query  languages,  report  generators,  and  report 
writers  are  often  features  of  a  DBMS  (for  example,  FCCOS, 
RAMIS  II,  and  NOMAD  provide  these  features) .  These  features 
allow  for  easy  data  retrieval  and  data  update.  Report 
generators  can  produce  complicated  reports  with  minimal 
programming  effort  [Bef.  61  ,  62,  79,  101  ]. 

c.  Graphics  Tools 

Graphics  are  ideal  for  representing  the  large, 
and  cften  complex,  structures  of  non-trivial  software 
designs.  These  tools  are  particularly  suited  for  the  ireth- 
odolcgies  which  use  structure  charts.  For  example.  Delisle 
[Ref.  102]  describes  a  set  cf  graphics-based  tools,  an  Sdit 
tool,  an  Evaluate  tocl,  a  Format  tool,  and  a  Clean-up  tool, 
which  were  developed  to  support  Structured  Analysis) . 

d.  High-level  Languages 

High-level  languages  (variously  described  as 
non- procedural  languages,  formal  specification  languages, 
and  so  on)  have  one  objective,  flexibility  [Ref.  62,  83, 

101].  Such  languages  enable  the  designer  to  describe"  what 
to  do"  rather  than  "hew  to  do"  it.  The  system  resolves  the 
procedure  and  should  produce  executable  machine  code.  The 
designer,  given  such  a  tocl,  can  use  abstraction  to  its 
fullest  extent  (the  Gamma  software  engineering  system 
[Ref.  103],  for  example,  specifically  supports  abstraction). 
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e.  Interactive  Systems 


|  Devices  and  equipment  (for  example,  working 

stations)  which  support  interaction  are  essential  [Hef.  61, 
62,  83,  98].  Interactive  terminals  give  users  and  designers 
the  perception  of  rapid  and  efficient  operation  and  revi- 
|  sion.  Generally,  these  facilities  are  adapted  from  the  host 

computer  or  network  of  the  SE2.  (Personal  development 
systems  cculd  be  thought  of  as  extensions  of  interactive 
systems.) 

f  f.  Applicaticn-ori ented  Models 

Models  are  an  important  feature  of  an  SE2.  They 
are  used  to  support  human  decision  making  [Ref.  61,  62]. 

jj  Examples  of  models  which  are  potentially  useful  are  finan¬ 

cial  xodels  (as  in  FOCUS)  or  simulation  models.  Real-world 
modelling  [Ref.  43]  is  also  an  important  element  in  the  SE2. 

g.  Tools  fcr  Software  Testing 

There  is  clearly  a  need  for  tools  which  simplify 
software  testing  [Ref.  83,  101].  Hausen  and  Muellerburg 

report  that  most  tools  of  this  type  concentrate  on  verifica¬ 
tion  and  validation,  that  is  convincing  ourselves  that  the 
program  will  execute  properly.  They  argue  that  software 
tools  fcr  program  testing  should  cover  more  than  just  veri¬ 
fication  and  validation.  They  recommend  a  philosophy  of 
quality  improvement  which  includes  quality  assurance 
(defining  software  standards  and  controlling  their  observa¬ 
tion)  ,  acceptance  testing  (demonstrating  to  the  user  that 
the  software  is  acceptable  for  operation),  and  verification 
and  validation. 
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•  Sutnort  for  Soft  ware  Design 

Any  SE2  aast  te  based  on  a  particular  view  of-  soft¬ 
ware  design.  [Ref.  €5,  94  ,  95  ,  97].  The  view  presented  in 
Chapters  II  and  III  is  unique,  although  elements  of  that 
view  may  be  supported  in  different  ways  by  different 
systeas. 

The  SE2  must  recognize,  and  provide  facilities  for, 
the  symaetrical  and  adaptable  process  of  design.  If  the 
solution  tc  a  problem  changes  the  problem,  features  cf  the 
SE2  must  allow  revision,  interactive  use  by  clients  (it  is 
their  problem,  after  all),  and  record-keeping,  especially  of 
decisions.’ 

The  satisficing  aspect  of  design  may  best  be  met  by 
using  the  modelling  tools  of  the  SE2.  Simulation  tools  can 
help  answer  "what  if"  and  performance  questions.  Financial 
models  can  help  decide  economic  questions.  Planning, 
control,  and  estimating  models  can  also  help  to  decide  on 
the  worth  of  various  tradeoffs. 

The  "wicked  problem"  aspect  is  particularly  vexing 
in  the  SE2.  High-level  languages  can  help  by  allowing  an 
abstract  description  as  a  formulation  of  the  problem.  The 
abstract  statements  are  then  transformed  by  the  system  into 
concrete  (that  is,  executable)  code  [Ref.  105,  106,  107], 

Communications  between  the  user  and  the  designer  is 
aided  by  interactive  systems.  Graphics  also  aid  user  (and 
designer)  comprehension.  Alexander  and  others  have  shewn 
how  the  notion  of  patterns  helps  bridge  the  communication 
gap.  Kuc,  and  ethers,  [Ref.  80,  84,  108,  109,  110,  HI] 
have  adopted  this  concept  in  their  "forms- based"  software 
development  environment.  The  'forms*  within  the  system  are 


’finite  [Ref.  104J  Dresents  a  model  for  recording  rele¬ 
vant  information  arout  design  decisions  durina  software 
development. 


used  to  identify  and  define  'patterns*  that  are  above  the 
level  of  programming  language  constructs.  Although  a  full 
discussion  of  the  TRIAD  (TRee-based  Information  Analyzer  and 
Developer)  system  is  beyond  the  scope  of  this  work,  it  is  an 
excellent  candidate  for  an  SE2  which  supports  software 
prototyping. 

The  interactive  facilities  and  modelling  features  of 
the  SE2  will  help  to  aid  the  learning  process  in  design. 
The  notion  of  'learning  by  doing'  was  introduced  in  Chapter 
III.  To  support  that  notion,  the  SE2  should  allow  the 
designer  to  learn,  early,  the  consequences  of  a  design  deci¬ 
sion.  The  designer  must  then  be  given  the  chance  to  revise 
his  decision,  based  cn  the  'operation*  experience. 

Organizational  issues  must  be  explicitly  recognized 
in  ary  SE2.  First,  there  are  organizational  resources  which 
are  needed  to  support  the  SE2:  programmers,  operators, 
managers,  space  and  facilities,  and  the  computer  hardware 
assocated  with  the  SE2.  Second,  the  work  patterns  and  work 
skills  cf  the  people  who  work  in  the  SE2  are  likely  to 
change.  Unfortunately,  most  current  development  environ¬ 
ments  stress  the  environment  over  the  users  of  the  environ¬ 
ment  [Ref.  98].  Typically,  those  environments  have  "quirks" 
which  require  people  to  adjust.  The  system  should  adjust  to 
the  skills  and  the  preferences  of  the  designers  who  use  it 
(using,  for  example,  custom  default  features).  If  we 
consider  the  SE2  as  an  element  of  a  complex  organization 
[Ref.  59,  60,  98  ],  the  environment's  interaction  with  people 
is  crucial;  without  that  interaction,  the  SE2  is  useless  in 
any  practical  sense. 

Finally,  the  SE2  must  explicitly  recognize  the 
evolutionary  aspect  of  software  design.  The  current  systems 
support  the  waterfall  model  of  software  development 
[Ref.  Sh,  95].  The  database  management  system,  interactive 
facilities,  and  high-level  languages  will  easily  support  the 
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evolutionary  concept  of  design.  Report  generators  and 
report  writers  should  aid  the  documentation  process  as  the 
design  evolves. 

3.  Succort  for  the  Prototype  Process 

The  process  of  developing  a  software  prototype  was 
covered  in  Chapter  IV.  There  are  four  steps  in  that 
process:  1)  identifying  the  user's  basic  requirements,  2) 

developing  a  working  prototype,  3)  ixplementing  ar.d  using 
the  prototype,  and  4)  revising  and  enhancing  the  prototype. 

an  existing  database  of  the  SE2  is  ideal  for  identi¬ 
fying  the  user's  initial  requirements.  However,  there  are 
problems  if  the  database  is  empty.  Kangasallo  [Ref.  112] 
presents  a  model  in  which  information  requirements  are 
interpreted  as  a  set  of  complex  queries  by  the  database 
management  system.  additional  features  of  that  model 
include  a  'program  constructor'  which  generates  code  tased 
on  the  queries.  a  working  prototype  is  a  result  of  this 
model. 

another  method  depends  not  only  on  the  database 
management  system  but  also  cn  the  automated  tools  within  the 
SE*.  Cheatham  [Ref.  105]  presents  a  system  in  which  the 
designer  and  user  develop  an  abstract  model  of  the  problem 
(possibly  from  the  database).  Transformation  refinement  is 
applied  (by  the  automated  tools)  which  results  in  executable 
code--a  working  prototype. 

In  both  of  these  instances,  the  SE2  supports  the 
development  of  the  user's  basic  requirments  followed  by  an 
automated  process  of  developing  a  working  prototype.  It  is 
important  that  some  effort  be  mads  to  analyze  the  user's 
requirements  so  that  reasonable  queries  can  be  made  and 
reasonable  models  (of  the  problem)  can  be  developed. 
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Other  systems  are  available  which  help  to  develop  a 
basic  set  cf  user  requirements.  Some  are  quite  complex 
[Bef.  32]  ard  night  be  difficult  to  integrate  with  the  SE2. 

Developing  a  working  prototype,  quickly,  should  not 
be  difficult  to  accomplish  in  the  SE2 .  High-level 
languages;  code  generators;  transfornation  refinement 
(mentioned  above);  application  development  systems,  such  as 
ACT/1  [Bef.  76]  and,  application  generators  [Bef.  75]  make 
it  easier  to  develop  working  prototypes.  Ideally,  the 
system  would  be  completely  automated. 

An  abstract  model  allows  the  designer  to  focus  more 
easily  on  the  results  of  his  or  her  decisions,  rather  than 
the  implementation  details.  An  abstract  model  also  promotes 
flexibility  when  it  is  reused.  [Bef.  105] 

Iaplementing  and  using  the  prototype  becomes  much 
easier  when  interactive  systems  are  used.  User  interaction 
is  essential  and  interactive  terminals  allow  the  user  to 
perceive  rapid  operation  and  revision.  They  also  help  to 
speed  user  evaluation  [Hef.  62]. 

Eevision  and  enhancement  are  facilitated  in  the  SE2 
by  using  the  database  management  system,  high-level 
languages  (and  abstract  models),  the  generalized  input  and 
output  tools,  and  graphics  tools.  The  database  contains  a 
record  cf  past  designs  and  design  decisions,  changes  are 
easily  made  to  abstract  models  and  high-level  language 
I  constructs,  default  values  of  the  generalized  input  and 

output  tools  are  easily  adjusted,  and  the  graphics  tocls 
will  enable  both  users  and  designers  to  spot  patterns 
;  quickly.  The  user  is  quickly  accommodated,  the  database 

!  management  system  automatically  tracks  versions  and  design 

decisions,  and  the  designer  is  able  to  defer  low-pricrity 
details  without  fear  of  compromising  the  design:  the  SE2 

relieves  the  designer  of  much,  if  not  all,  of  the  drudgery 
I  normally  associated  with  software  design. 
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D.  S0HH1ET 


The  preceding  sections  have  reviewed  the  characteristics 
needed  in  a  software  engineering  environment,  have  identi¬ 
fied  the  components  of  a  software  engineering  environment, 
and  have  described  hew  the  components  interrelate  to  support 
both  software  design  and  the  prototype  process. 

It  is  dcubtful  that  there  are  any  software  engineering 
environments  which  support  completely  the  idea  cf  proto¬ 
typing.  Tc  a  limited  degree,  commercial  systems,  such  as 
FOCOS,  NCMAD,  ACT/1,  to  name  a  few,  support  particular 
aspects  cf  the  prototype  process.  For  example,  FCCUS  and 
NOMAD  facilitate  applications  programming  in  the  business 
community  by  allowing  the  designer  to  customize  reports  or 
other  appplications  for  a  specific  user,  or  group,  based  on 
an  already  existing  databa se--the  vice-president  of  sales 
might  be  interested  in  the  sales  of  a  particular  product  in 
a  particular  geographical  area.  ACT/1,  and  other  similar 
products,  make  it  easier  for  designers  to  customize  the 
formats  cf  terminal  screens  for  the  user. 

The  products  mentioned  here  are  three  of  several  hundred 
commercial  and  research  systems  and  environments.  This 
chapter  has  purposely  avoided  a  lengthy  review  of  any  of 
those  hundreds,  and  mentions  a  few  by  way  of  example  only. 
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fl.  CASE  BIAHPLES 


The  four  cases  which  follow  were  chosen  because  in  each 
there  was  an  explicit  decision  began  to  develop  and  use 
software  prototypes  before  the  project  began. 

A.  SYHHIIHT,  EfOLDTICH,  SATISFICIIG,  AID  COHHDMICATION 

Heckel  [Bef.  113]  describes  the  process  of  developing  a 
ptototype  while  designing  the  Craig  translator.  The  project 
team  explicitly  chose  to  develop  prototypes  for  several 
reasons.  First,  they  were  concerned  about  the  problems 
which  users  would  actually  experience,  rather  than  these 
problems  which  the  designers  imagined  might  be  important. 
This  concern  is  directly  related  to  the  symmetry  aspect  in 
design.  That  is,  tfce  solution  and  problem  interrelate  such 
that  the  solution  depends  critically  upon  the  context  cf  the 
problem.  In  this  case,  the  context  is  the  consumer's  use  of 
the  Translator.  If  the  product  does  net  perform  as 
"expected",  it  will  net  sell. 

Second,  the  project  team  was  interested  in  postponing 
decisions  about  restraints  on  the  final  system  until  they 
had  to.  In  other  words,  their  design  evolved.  The 
designers  ignored  certain  restrictions  which  had  been  placed 
on  memory  size,  as  long  as  they  carefully  considered  the 
effects  of  their  decisions  on  the  production  version  of  the 
Translator. 

Third,  the  project  team  planned  to  use  the  prototype  as 
the  software  specification.  Because  they  had  two  "versions" 
of  the  prototype,  a  black  box  translator  and  the  program 
listing,  they  thought  that  they  would  avoid  the  traditional 
misunderstandings  and  contradictions  often  found  in  written 


software  specif icaticns.  In  this  case,  the  designers  were 
concerned  about  communications,  not  only  between  the  ‘'user" 
and  the  "designer”  bat  also  aaong  theaselves. 

Heckel* s  description  shows  that  the  prototypes  (there 
were  30  versions!)  were  ased  to  clarify  reguireaents  and  to 
verify  the  feasibility  of  the  design.  Heckel  states  that  if 
they  had  been  forced  to  nake  a  particular  design  decision 
earlier  than  they  did,  they  probably  would  have  aade  a  less 
satisfactory  decision. 

The  project  was  judged  a  success,  although  progress 
seeaed  slew  and  painful.  Heckel  identifies  four  benefits  of 
developing  prototypes: 

1.  The  project  teaa  could  keep  trying  new  things; 

2.  The  prototype  was  a  good  model  of  the  final  product, 
sc  everyone  had  similar  expectations  about  what  the 
product  would  do; 

3.  Several  decisions  could  be  postponed  without 
affecting  the  schedule;  and, 

4.  The  designers  focused  their  efforts  on  opportunities 
rather  than  problems. 

The  development  process  had  some  disappointments:  soft¬ 
ware  development  tock  longer  than  expected  and  the  final 
product  tcok  more  memory  than  expected.  Heckel  did  not 
speculate  on  whether  these  "disappointments”  could  have  been 
avoided.  One  interpretation  is  that  the  designers  were 
unable  tc  meet  all  of  their  objectives  and  when  time  ran  out 
their  design  was  judged  to  be  good  enough.  Thus,  the 
"disappointment s"  can  be  attributed  zo  the  satisficing 
aspect  of  design,  especially  the  need  for  more  memory.  The 
designers  obviously  made  a  trade-off  between  the  "goodness" 
of  the  product  and  the  amount  of  memory  they  had  originally 
planned. 
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This  case  illustrated  how  the  use  of  prototypes 
addresses  the  symmetry.  evolution,  commun icatlons.-  and 
satisficing  aspects  of  design. 

B.  LE1HHIHG 

Hemenway  and  McCusker  [  Bef .  116]  describe  an  exploratory 
project  which  is  leading  to  the  development  of  an  order 
negotiation  and  entry  support  system  for  telephone  service 
(the  Bell  system).  The  project  is  the  development  of  the 
user  interface  and  the  supporting  software  for  the  system. 

There  are  two  reasons  given  for  building  an  operational 
prototype:  1)  to  evaluate  the  user  interface  and  2)  to 
assess  the  feasibility  of  a  particular  software  architec¬ 
ture.  Even  thcugh  the  reasons  coincide  with  two  uses  of 
prototypes  (that  is,  to  clarify  user  requirements  and  to 
verify  the  feasibility  of  a  design)  they  are  related  tc  two 
aspects  of  design.  The  aspects  are  learning  and  communica¬ 
tion  between  the  designer  and  user. 

Prototypes  of  the  software  were  daveloped  to  determine 
whether  a  table-driven  system  could  be  designed.  Prototypes 
of  the  user-interface  were  used  to  determine  whether  the 
user-interface  wculd  subst antially  increase  the  length  of 
time  service  representatives  spend  on  orders  (compared  to 
manual  crder  entry  ard  search)  . 

The  case  concludes  by  stating  that  the  results  of  the 
prototype  evaluation  led  to  making  several  recommendations 
to  the  designers  of  the  first  release  of  the  system.  Hence. 
the  prototype  served  to  hel p  the  designers  learn  more  about 
their  sciuticn  their  problem . 
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C.  NICKED  EBOBLEMS,  COMMON ICATIONS,  AND  THE  ORGANIZATIONAL 

CONTEXT 

Jenkins  [Ref.  114]  discusses  how  the  decision  tc  develop 
a  prototype  led  to  successful  development  of  an  automated 
data  processing  facility  for  the  Congressional  Budget 
Cff ice. 

Two  aspects  of  software  design  are  apparent  in  this 
case:  1)  communications  between  users  and  designers  and  2) 

the  organizational  context  of  the  system.  Communications 
between  the  designers  and  users  was  greatly  improved  by 
using  a  prototype.  Bather  than  try  to  decide  on  the  design¬ 
er's  effectiveness  by  reviewing  written  specifications, 
managers  witnessed  operating  demonstrations.  The  prototype 
also  shewed  non-technical  users  what  it  was  possible  to  do 
in  their  application  areas  with  the  new  tools. 

By  far  the  most  important  aspect  illustrated  by  this 
case,  is  the  concern  of  the  designers  for  organizational 
issues.  The  Congressional  Budget  Office  serves  the  needs  of 
the  Congress,  admittedly  a  complex  organization.  so,  the 
designers  needed  immediate  responses  to  congressional 
inquiries,  because  when  information  is  needed,  it  is  often 
needed  immediately  or  its  value  is  lost. 

This  organizational  aspect  is  also  closely  related  to 
wicked  problems.  Becall  that  wicked  problems  refer  tc 
social  system  problems  which  are  ill-formulated,  where  the 
information  is  confusing,  where  there  are  many  clients  and 
decision-makers  with  conflicting  values,  and  where  the 
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ramifications  in  the  whole  system  ar9  thoroughly  confusing. 
Clearly  Congress  is  faced  with  these  kinds  of  problems. 
There  is  every  reason  to  expect  that  the  Congressional 
Budget  Office  deals  with  similar  problems  when  responding  to 
Congressicnal  inquiries. 10 

The  ca.se  presented  by  Jenkins  illustrates  how  prototypes 
can  aid  software  design  when  faced  with  critical  organiza¬ 
tional  issues  and  wicked  problems . 

D.  COHHONICATION,  LEARNING ,  AND  EVOLUTION 

Groner  and  others  [Ref.  115]  present  a  case  cf  using 
prototypes  to  clarify  the  user's  requirements.  The  case  is 


unusual  because  it  started  with  a  proposal  from  outside  the 
user's  community.  The  designers  set  out  to  determine  if  and 
how  computer  technology  could  meet  the  information 
processing  needs  of  medical  researchers. 

This  case  is  a  clear  illustration  of  the  importance  of 
communications  between  the  designer  and  the  user  and  the 
representation  used  for  communicating. 


Prototypes  were  required  in  the  requirements  analysis 
phase  because  without  concrete,  working  examples  our 
potential  users  could  not  be  sura  that  computer  systems 
are  needed,  what  functions  they  should  perform,  or  how 
they  wculd  use  them.  [Ref.  115  :  p.  100] 


Less  clearly  stated  is  the  implication  of  learning 
during  the  design  process.  The  intitial  design  of  the 
prototype  was  based  on  the  designer's  knowledge  about 


10Consider  the  fluctuations  from  Congress  to  Congress, 
chairman  to  chairman,  committee  to  committee:  from  year  to 
year,  week  to  week,  and  even  from  hour  to  hour  during  the 
Budget  Committee  markup  sessions  [Ref.  114  :  p.  22]. 
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information  processing  needs  for 
Subsequent  versions  were  improved  based 
comments  frcm  clinical  researchers.  The 
pants 


resear  ch. 
on  use  by  and 
project  pa'rtici- 


.  .  .  agreed  to  learn  about  each  other's  disciplines, 
then  define  problems  and  attempt  no  devise  and  evaluate 
solutions  in  collaboration  with  others  in  the  target 
user  community.  [  Bef .  115  :  p.  101] 

The  project  used  an  incremental  implementation  strategy 
(evcluticn)  under  which  major  software  releases  ware  sched¬ 
uled  approximately  every  four  months.  Several  hundred  soft¬ 
ware  changes  were  made  over  a  period  of  a  year  and  half. 
This  case  shows  how  prototypes  can  be  used  to  create  the 
final  system.11 

The  case  presented  by  G  roner  and  others  is  an  excellent 
example  of  hew  c cmmunica tions,  learning,  and  evolution  are 
intertwined  in  software  design .  The  development  cf  proto¬ 
types  helped  all  of  the  design  participants  cope  with  those 
aspects  cf  soft  ware  design . 

E.  S0HN1BY 

These  cases  illustrate  how  prototypes  help  designers 
cope  with  the  seven  aspects  of  design  which  were  covered  in 
Chapters  II  and  III.  In  each  of  the  cases,  the  authors 
point  to  success.  For  Heckel,  the  prototypes  led  no  a 
product  that  was  easy  to  use,  had  a  number  of  useful 
features,  and  was  implemented  on  a  single-chip  micropro¬ 
cessor. 


‘‘Th?  case  description  leads  the  reader  tc  think  that  a 
"production"  system  was  not  developed.  Every  indication  is 
that  the  prototypes  evolved  into  tne  production  system. 
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Hemenway  and  McCusker  say  only  that  prototype  evaluation 
led  to  recommendations  to  the  designers.  From  this,  we  can 
safely  infer  that  the  prototype  aided  the  designer '  s  'under¬ 
standing  of  the  problem. 

For  Jenkins,  the  overall  assessment  to  the  prototype  was 
positive.  Managers  liked  the  idea  of  a  prototype  because 
there  was  no  prior  commitment  to  a  particular  course  of 
action. 

Groner  and  others  believe  that  the  greatest  benefit  of 
the  prototype  is  that  the  prototypes  are  concrete,  working 
examples  cf  computer  systems  which  are  meeting  everyday 
needs . 
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¥11.  COHCLOSIOHS 


1  new  view  of  design  was  presented  in  Chapter  II.  This 
view  identifies  a  set  of  seven  interrelated  and  mutually 
dependent  elements  which  were  found  in  the  literature. 
Support  for  these  elements  was  found  throughout  the  computer 
and  information  science  literature.  The  set  of  seven 
elements  explains  how  best  to  cope  with  the  problems,  ambi¬ 
guity,  and  uncertainty  associated  with  software  design. 

The  process  of  developing  a  software  prototype  is 
presented  as  the  most  appropriate  way  to  incorporate  the 
design  elements  into  software  design.  In  fact,  the  proto- 
type  process  exploits  certain  elements,  such  as  communica¬ 
tion  between  the  user  and  designer,  to  improve  the  overall 
design  of  the  software. 

Cne  of  the  more  important  conclusions  is  that  software 
designers,  especially  designers  of  large-scale  systems,  have 
much  to  learn  from  designers  in  other  fields.  The  software 
design  literature  shews  little  evidence  of  influence  from 
other  design  fields.  This  work  is  a  start  toward  that 
needed  transfer  cf  knowledge. 

The  software  prototype  may  be  the  sensible  way  tc  design 
large-scale  systems.  Recall  that  complex  design  problems 
have  been  called  wicked  problems.  If  some  large-scale 
system  developments  are  'more  wicked'  than  others,  then 
developing  prototypes  seems  to  be  the  only  way  to  design  the 
system. 

Software  prototyping  enables  users  and  designers  to  cope 
with  ill-defined  problems  and  changing  requirements.  Past 
experience  indicates  that  bad  technical  engineering  is  not  a 
problem  with  software  development.  Rather,  unsatisfactory 
design  decisions  and  faulty  information  are  the  real 
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problems.  Software  prototypes  provide  a  mechanism  which 
allows  designers  to  test  their  decisions  and  to  learn  acre 
about  the  problem.  The  prototypes  also  allow  users  a 
construcyive  environment  in  which  to  express  their  satisfac¬ 
tion  cr  dissatisfaction  and  a  stimulant  in  learning  hew  to 
deal  with  their  problems. 

Software  prototypes,  however,  present  special  difficul¬ 
ties  because  they  are  not  the  universal  remedy  for  software 
design  problems.  Careful  management  is  needed  to  ensure  the 
software  ptototype  is  really  designed  and  net  just  put 
together.  Careful  thought  and  planning  are  necessary  before 
coding  begins.  Managers,  designers,  and  users  must  remember 
that  a  software  prototype  is  an  experiment.  Judgement  and 
commitment  are  needed  to  control  endless  iterations. 
Managers  must  have  the  wisdom  to  know  when  to  stop.  Often, 
while  developing  successive  prototypes,  there  is  a  tendency 
to  delay  formally  documenting  the  system.  While  this 
problem  is  not  unique  to  prototypes,  there  must  be  attentive 
management  and  commitment  to  ensure  adequate  and  complete 
documentation. 

In  spite  of  these  cautions,  evidence  indicates  that 
developing  ar.d  using  software  prototypes  is  the  best  option 
for  coping  with  software  design  problems,  for  ensuring  the 
system  is  delivered,  and  for  ensuring  a  satisfied  user 
popular icr. 


VIII .  RSCOBHEH DAT  IONS  FOR  FOBTHER  STUDY 


A.  H AHAGEHENT 

Developing  software  prototypes  presents  management  with 
some  unusual  problems.  Many  of  our  current  management  tech¬ 
niques  depend  on  getting  the  project  done  right  the  first 
time  [Ref.  117].  As  we  are  well  aware,  this  seldom  occurs. 
Research  is  needed  to  assess  the  effect  of  prototype  devel¬ 
opment  on  management. 

1.  Hew  does  the  manager  decide  when  to  cease  development 
of  prototypes?  When  is  the  project  ended? 

2.  Hew  dc  managers  deal  with  increased  communications 
between  users  and  designers?  If  special  management 
controls  are  needed,  how  far  should  they  go? 

3.  what  management  style  best  suits  managers  of  software 
prototype  projects? 

4.  How  is  the  project  budgeted  and  controlled?  Hew  is 
progress  measured? 

B.  ACQUISITION  AND  CONTRACT  HABAGEMENT 

Current  acquisition  and  contract  management  procedures 
and  regulations  for  software  appear  to  be  less  than  satis¬ 
factory,  within  the  Federal  Government  generally,  and  the 
Department  of  Defense  particularly.  Even  as  these  proce¬ 
dures  and  regulations  are  changing,  there  is  some  evidence 
that  the  traditional  model  of  software  development  may 
become  reguired.  The  Department  of  Defense  has  begun  to 
address  the  concept  of  software  prototypes  in  the  DoD 
Software  Technology  Initiatives  [Ref.  DoD81  :  p.  69-71],  but 
this  research  appears  to  be  concerned  only  with  requirements 
specifications. 
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1.  Hew  can  or  how  should  acquxtition  and  contract 
management  procedures  and  regulations  accomodate  the 
principles  of  design  and  software  prototypes? 

2.  Shat  is  the  best  strategy  for  encouraging  acceptance 
of  the  software  design  principles  and  software  proto¬ 
types? 

3.  How  might  the  elements  of  software  design  and  devel¬ 
oping  software  prototypes  help  with  the  acquisition 
and  contract  management  for  embedded  computer 
resources? 

C.  OBGAHIZ  AH  ON  AL  CONTEXT 

Kling  and  Scacchi  [Hef.  59,  60]  reviewed  a  large  number 

cf  organizational  studies  while  developing  their  views  about 
the  effect  of  computer  systems  upon  organizations.  When 
their  ideas  are  considered  within  the  context  of  software 
prototypes,  further  research  is  needed. 

1.  How  will  chances  in  theories  of  organizational  devel¬ 
opment  affect  the  process  of  developing  prototypes? 

2.  Is  any  one  organizational  theory  best  suited  for 
software  design  and  software  prototypes? 

3.  What  are  the  social  dynamics  of  software  design? 

4.  What  are  the  social  dynamics  of  developing  software 
prototypes? 


D.  QUALITY 

A  fundamental  part  of  design  is  to  satisfy  the  needs  for 
quality.  Hooke  [Hef.  Book82]  has  concluded  that  design  is 
the  mest  important  factor  in  determining  overall  quality. 
Even  though  one  of  the  objectives  of  developing  software 
prototypes  is  to  achieve  user  satisfaction  (a  major  element 
cf  quality)  ,  research  is  needed  to  determine  how  prototypes 
can  affect  software  quality. 


1.  If  we  accept  that  prototypes  will  affect  a  change  in 
software  technology,  how  will  that  change  influence 
our  perceptions  of  quality?  That  is,  will  software 
prototypes  lead  users  to  expect  more  than  can  be  met? 

2.  How  might  the  concept  of  Quality  Circles  fit  the 
process  of  developing  software  prototypes? 

3.  To  what  extent  will  software  prototypes  influence 
software  quality?  Since  prototyping  requires 
concensus,  who  is  ultimately  responsible  for  product 
quality  and  liability?  Should  anyone  be  "ultimately" 
responsible? 

E.  REPRESENTATION 

The  software  prototype  is  the  ultimate  representation  of 
the  user's  requirements.  The  written  specification  anchors 
the  other  end  of  the  representations  scale. 

1.  What  other  types  of  representations  can  aid  software 
design  and  the  development  of  software  prototypes? 

2.  What  methods  are  suitable  for  representing  abstrac¬ 
tions  when  identifying  a  user's  requirements  before 
developing  a  software  prototype? 

3.  Hew  do  different  representations  affect  our  percep¬ 
tions  and  real  world  knowledge?  Can  different, 
initial  representations  lead  to  quicker  design  and 
development  of  software  prototypes? 
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